Ce petit post, sans valeur technique, pour vous indiquer qu’une longue série de posts Java vs C# va suivre ! Côté langage, côté API… C# sera pour .NET le langage référent mais les amateurs de VB.NET ne seront pas déçus. Alors tenez-vous prêt ;-)… Evidement, ceci ne m’empêchera pas de faire des posts sur C++, Objective-C, TFS, WCF, etc.

Bizarre ? Vous avez dit bizarre ?
Effectivement, après plusieurs années d’expérience, c’est la normalité qui est bizarre en informatique.

Plus sérieusement, un petit message sérieux aujourd’hui sur Team System en lançant plusieurs tâche Winrm. Je vous laisse en apprécier la teneur.

Le message est clair mais pourtant surprenant, mes scripts TFS s’occupant certes du déploiement (les workflows ont été personnalisés sous Worfklow Foundation, ils nécessitent des assemblies complémentaires et mieux, au niveau du Build Definition, des Custom Editors sont fournis^^), mais pas pour occuper les 200 connexions autorisées par défaut !

Bien que je cherche encore le comment du pourquoi… Voici un petit « quick and dirty » workaround !!

A partir de Windows 2008 R2, il faut exécuter les commandes suivantes :

En deçà, voici les commandes

Un programme est bloqué sur votre machine Windows ? Facile, task explorer, on sélectionne l’application ou le process, bouton droit « End Task « et tout s’arrête.
Mais comment faire lorsque plusieurs instances du même programme sont lancés ?

J’ai récemment aidé un développeur dont le programme lançait plusieurs tâches net.exe ; ceci afin de déploiement des composants réseaux et nombre de ces process (tous ?) restaient en mémoire.
Afin de tuer toutes ses tâches d’un coup, il existe une commande simple « taskkil » qui accepte un filtre en option (/fi) ; lequel permet par exemple d’indiquer de killer tous les process dont l’image porte un nom comme dans l’exemple suivant.
taskkill /f /fi « IMAGENAME eq net.exe »

Dans la même idée, on peut via une seule instruction mettre une fin à tous les programmes qui ne répondent pas

taskkill /f /fi « status eq not responding »

D’autres options sont disponibles en tapant taskkill / ?

A l’heure du Cloud, le CQRS est un des patterns absolument connaître.

Le Command Query Responsibility Segregation est un pattern simple qui dissocie les opérations d’écritures des opérations de lecture.
Fondamentalement parlant, le CQRS est un pattern qui dissocie les opérations de commandes (les opérations d’écritures) des opérations d’interrogation (les lectures). Ainsi codé, par un système d’évènement et de synchronisation optimiste des locks, on peut gagner énormément en throughput car on limite les opérations de verrouillage (lock)  dans le système sous-jacent (souvent une base de données).

Conceptuellement parlant, le CQRS repose sur une logique où la donnée qu’on manipule existe sous 2 visions. Une vision informative, d’affichage, de requête, qui ne reflète pas forcément le réel (par exemple, le nombre de places disponibles dans un théâtre) et une vision de commande, de transaction, d’écriture, qui exige de travailler avec des données réelles (le moment où l’on réserve vraiment)
Le CQRS prend tout son sens dans des architectures demandant de la performance ou de grandes montées en charge. On choisit d’impacter le fonctionnel, le perçu client (le client qui réserve une place de théâtre, ne sera sûr de l’avoir qu’au moment du paiement) au profit des performances et de la simplicité du système (le CQRS est un pattern simple qui n’exige pas des mécanismes compliqués de synchronisation. Dans notre exemple du théâtre, bloquer des places pendant les commandes d’un utilisateur impliquent des mécanismes de synchronisation en base de données, session, etc.).

http://code.msdn.microsoft.com/windowsazure/CQRS-on-Windows-Azure-125d11d1
http://martinfowler.com/bliki/CQRS.html

WinRM est l’implémentation WS-Management de Microsoft.

Fonctionnant sur SOAP, cette technologie permet l’administration de machine à distance. WinRM est en version 2 pour le moment, fonctionne sur les derniers OS de Microsoft, fonctionne sur du Windows 2003 mais possède une limitation, il faut le SP2. C’est une sévère limitation si vous souhaitez utiliser Powershell v2 qui nécessite WinRM 2.0.

Il est classique dans l’écosystème d’un SI que des serveurs Windows ne soit pas dans les derniers services pack… Heureusement, Microsoft fournit depuis peu WS-Management 1.1 spécifiquement pour cet OS et pour Windows XP.
Il y a toutefois une limitation concernant Powershell. En effet, l’avantage de WinRM ne réside pas tant dans WS-Management que dans PowerShell qui vient directement s’interfacer à lui.
PowerShell 2 couplé à WinRM 2 permet l’administration de machine distante dans le nouveau langage de shell extensible de Microsoft.

Outils
L’installation de WinRM fournit 2 outils :
– winrm pour la configuration, le traitement de tâche WS-Management y compris à distance
– winrs, un client sur winrm

Astuces d’installation

L’installation de WinRM 2 et PowerShell 2 est très aisé sur des postes configurés classiquement, de simples clics et tout y est. Idem pour WS-Management 1.1.
Toutefois, un problème de taille peut subvenir lors de l’installation. En effet, WS-Management/WinRM impose l’activation du Firewall Windows sur les machines. C’est en soi une très bonne idée, mais en même temps un très gros problème pour les machines qui ne l’active pas ; reposant sur d’autres mécanismes.

Sur une machine où le firewall est activé, il suffit de lancer la commande 1 du tableau ci-dessous. Pour information, sur une machine Windows 2008 où WinRM est installé, cela se passera sans encombre. Dans le cas de figure où il n’y a pas de firewall, il faut exécuter les commandes de la ligne 2 du tableau ci-dessous (à l’exeption de la dernière).
Information cruciale, entre WinRM 1.1 (à comprendre WS-Management 1.1) et WinRM 2.0, il y a eu des changements de ports.
Dans la première version, tout s’effectuait sur le sports standard HTTP et HTTPS, à savoir 80 et 443. Dans la seconde version, les nouveaux ports sont 5985 et 5986. Dans une communication WinRM 2 vers WinRM 1.1 (ou dans l’autre sens), il faut penser à préciser les ports

Voici donc quelques commandes à connaître :

1	winrm quickconfig	Permet la configuration de WinRM en ligne de commande. Démarre le service et créé les listeners associés. Démarre le firewall windows nécessaire au fonctionnement de WinrM
2	sc config « Windows Remote Management » start=auto net start WinRM winrm create winrm/config/listener?Address=*+Transport=HTTP netsh firewall add portopening TCP 80 « Windows Remote Management »	Les commandes suivantes reproduisent plus ou moins à l’identique le fonctionnement de WinRM quickconfig (en pratique winrm quickconfig ouvre le port TCP 80 et 443, je ne l’ai pas détaillé ici) . Si la commande WinRM quickconfig ne fonctionne pas, il y a de grandes chance que le Firewall Windows ne soit pas démarré. On pourrait lancer ce dernier mais avec le risque suivant. Nous accédons aux machines distantes via RDP (mstsc). Le démarrage du firewall pourrait couper la connection. Les commandes suivantes indiquent précisément ce que fait winrm quickconfig.Vous remarquerez la dernière ligne de nos commandes. Avec winrm quickconfig, si elle plante, c’est comme si les autres n’avaient pas été exécutées. Faite une à une en ligne de commande(à l’exception de la dernière si vous n’activer pas le firewall) , vous pouvez reproduire le comportement de winrm quickconfig ^^
3	winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password ipconfig	Lance la commande ipconfig sur la machine machine76. Dans notre exemple l’appel à lieu sur le port 80 car ladite machine est installé avec WinRM 1.1 (WS-Management 1.1). Le port est ici précisé car le client winrs a été lancé à partir de la machine machine313 équipée de WinRM2.0. Sur une machine cliente WinRM 1.1, aucune précision n’aurait été nécessaire.
4	winrm set winrm/config/client @ {TrustedHosts= »machine313, foo,bar »}	Ajoute les machines machine313 , foo et bar dans la liste des TrustedHosts (pas besoin d’authentification. Pratique pour de la communication inter domaine)
5	winrs -r: http://machine76:80 -u:OtherDomain\JEAN-FRANCOIS -p:password iisweb /start MONSITE	Démarre le site web MONSITE sur la machine machine76 (Pour arrêter le site web, mettre /stop à la place de /start)
6	winrm enumerate winrm/config/listener	Enumère les listeners sur WinRM. Cette commande permet de vérifier l’accessibilité à distance de la machine sur laquelle on l’exécute.
7	Winrm get wmicimv2/Win32_Service?Name=spooler	Cette commande permet de vérifier que WinRm fonctionne en local. On demande l’état du spooler d’impression
8	winrm get winrm/config	Cette commande permet de savoir la configuration de WinRM sur la machine sur laquelle il est lancé
9	winrs -r: http://machine313:5985 -u:Domain\user -p:password ipconfig	Lance la commande ipconfig sur la machine machine313. Dans notre exemple l’appel à lieu sur le port 5985 car ladite machine est installé avec WinRM 2. Le port est ici précisé car le client winrs a été lancé à partir de la machine machine76 équipé de WinRM1.1. Sur une machine cliente WinRM 2.0, aucune précision n’aurait été nécessaire.

En cas de problème
– Essayer de configurer le TrusteHosts sur les 2 machines devant communiquer

J’adore Jboss et depuis très longtemps. J’ai commencé à travailler avec une version 2.2.2 et ai connu le passage au clustering (v3) puis les migrations et évolutions successives. L’un des rares serveurs applicatifs que les équipes de production n’hésitent pas à déployer…
L’un des seul… Avec Glassfish ! Soutenu par Oracle (et Sun avant lui), parfaitement intégré à Netbeans, je le conseille fortement pour ceux qui veulent à partir de rien sur leur machine coder rapidement comme sur VS 2010 😉

Ce pattern, ou plutôt cet antipattern, est très bien connu des développeurs seniors, architectes ou tous ceux qui ont une passion certaines pour l’informatique et qui se sont penchés sur des problématiques d’optimisation en environnement multithread.

Je tiens à vous rappeler ici les principes de cet antipattern qui en réalité n’en est pas un en logique pur ! Que je m’explique, l’antipattern au sens où on l’entend classiquement, est  une violation des principes objets ou des  principes de design applicatifs. Pour l’avoir vécu, un feu EJB entity (je parle de ces bons vieux EJB entity BMP, CMP que JPA grâce à Hibernate a fini par tuer) qui appelle un EJB session est un antipattern. Pour ceux qui ne connaissent pas, on ne fait pas une couche d’accès aux données remonter au niveau de la couche de services.  Cela viole les principes de séparation des couches et de responsabilités. Cela peut également créer des  problématiques de référence circulaire contourné par des antipatterns encore plus affreux. Dans le cas des EJB entities, cela pouvait même amener des problématiques de performance…

Le double-checked locking, lui, ne viole aucun principe de design ou objet. Quelqu’un qui maîtrise le threading peut réussir à le mettre en oeuvre par pure réflexion, sans penser une seconde qu’il se trompe. Et le pire, c’est qu’il n’y a pas de problématique de raisonnement ; il faut simplement connaître le problème, sinon on ne le contourne pas.

Bon, de quoi parle-t-on ? Qu’est-ce que le double-checked locking ?

Pour le comprendre, commençons par créer un Singleton en Java

public class MonSingleton {
    private static MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }
    // Méthodes
}

En multithread, un bug peut se créer au niveau du getInstance. Imaginons 2 threads, thread 1 et thread 2 qui se retrouvent en simultanée dans la méthode getInstance. Iml’ginons que thread1 soit juste avant l’appel à new MonSingleton que l’ordonnanceur donne le contrôle à thread 2. Il rentre dans la méthode getInstance, « instance » est toujours nul donc il rentre dans le if. L’ordonnanceur donne le contrôle à thread 1 qui fait sont new MonSingleton(), retourne ensuite une instance… Puis thread 2 s’exéute, créé son instance  et retourne donc un nouveal object, pas le même que thread 1. Nous n’avons donc pas créé un singleton en multithread. Pour info, ceci n’est pas obligatoirement gênant mais vous pourriez être dans un ccas de figure où ça l’est.

Comment éviter ceci ? Premier réflexe, utiliser synchonized en Java ou lock en C#.

public class MonSingleton {
    private static MonSingleton c = null;
    public static synchronized MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }

L’inconvénient de cette méthode, qui marche très bien, est qu’elle dégrade les performances. En effet, l’appel à getInstance se fait en série. Il n’est pas possible à 2 threads d’obtenir l’instance même si celle-ci a été créée.

Le double-checked locking peut alors être mis en place

public class MonSingleton {
    private static MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null {
              synchronized (Singleton.class){
                 if (instance == null) {
                      instance = new MonSingleton();
                 }
              }
        }
        return instance;
    }

Aucun problème de logique ici. On décale au plus tard la phase de lock et on ne synchronise que la partie qui nous intéresse. En faisant ainsi on pense avoir trouvé la solution idéale… Mais il y a un hic !! Ce hic est la façon dont fonctionne les compilateurs et les processeurs qui réordonnent les instructions. Les processeurs  utilisent également leurs registres pour accéder plus rapidement aux variables plutôt qu’en les lisant en RAM.La solution ne tient pas à grand chose. En C#(depuis le début) et Java (depuis Java 5), le mot clé « volatile » est la solution.

public class MonSingleton {
    private static volatile MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null {
              synchronized (Singleton.class){
                 if (instance == null) {
                      instance = new MonSingleton();
                 }
              }
        }
        return instance;
    }