Windows Azure SDK 1.5 et l’erreur “DevFC.exe stopped working”

Apres installation du SDK Azure 1.5 sur mon poste de développement, l’émulateur Azure (Windows Azure Compute Emulator) ne pouvait plus démarrer. Une boite de dialogue d’erreur “DevFC.exe stopped working” indiquait le crash de l’émulateur du Fabric Controller de l’émulateur.

Pourtant tout fonctionnait bien avec le SDK 1.4

Solution brute : je fais une VM pour mon Dev … mais je ne sais toujours pas ce qui coince sur mon poste de développement originel.

Solution finaude : Analyser les logs, et aimer la ligne de commande

Les logs du FabricControler de développement se trouve dans C:\Users\[VOTRE_USER_NAME]\AppData\Local\dftmp\DevFCLogs.

En analysant ce fichier, on trouve une exception :

Exception occurred when trying to open service host. {0}, {1}`Il existe déjà un écouteur sur le point de terminaison IP 127.0.0.1:12000. Vérifiez que vous n’essayez pas d’utiliser ce point de terminaison plusieurs fois dans votre application et qu’aucune autre application n’écoute sur ce point de terminaison.`

Tout est dans le message : un autre programme occupe le port IP 12000 que cherche à utiliser DevFC.exe. 

Pour savoir quel programme utilise ce port, ouvrez une invite de commande, et exécuter la commande “netstat –b –n –a” pour lister tous les ports IP utilisés sur le système et quel programme les utilise :

Et je découvre que le port 12000 est utilisé par le programme “htcUPCTloader.exe” … programme de gestion des terminaux Android HTC.

Je stoppe le programme avec le gestionnaire de tache, redémarre le “Compute emulator” … et tout marche à merveille, je peux déployer mes applications Azure dans le Compute Emulator.

 

Dans mon cas, il s’agissait du port 12000 occupé par htcUPCTLoader, pour d’autres cas recensés il s’agit du port 12001 occupé par VMWare. La procédure pour identifier l’origine reste la même.

 

Espérons que Microsoft corrige ce désagrément en mettant en place une sélection automatique des ports.

Les primaires électorales … ou l’intérêt des architectures élastiques

Loin de moi l’idée d’utiliser mon blog technique pour faire de la politique. Au contraire, je vais utiliser un évènement politique pour parler d’architecture logicielle.

Aujourd’hui (dimanche 9/10/11 [jolie suite au passage]), Le parti socialiste organisait le premier tour de leurs primaires afin de choisir un candidat pour la prochaine élection présidentielle française. Les bureaux de vote ne se trouvant pas forcement dans leur lieu habituelle (en mairie), un site web (http://bureauxdevote.lesprimairescitoyennes.fr/) a été mis en place afin de permettre à tout un chacun de trouver le bureau de vote correspondant à son domicile. Initiative louable, et surtout mis en œuvre suffisamment tôt avant le vote pour permettre de tester le site, ou pour le votant de vérifier avant le rush final son lieu de vote.

Malgré cela, l’affluence des visiteurs sur le site ce dimanche à été tel, qu’il a rapidement cesser de fonctionner correctement, renvoyant un message joliment formaté mais totalement inutile pour le potentiel votant :

Cet état a perduré assez longtemps, puis dans l’après midi, la page de recherche a été remplacé par une page HTML pure et dure :

Liste par ailleurs généré directement à partir d’Excel (cf. les méta données), ce qui indique l’incapacité du prestataire ou de l’équipe technique à faire monter en charge rapidement leur site, ou leur hébergement.

 

L’hébergement du site de recherche sur une architecture de type “cloud” aurait permit de profiter de l’élasticité offerte par ces plateformes de cloud computing, c’est à dire la capacité à adapter de manière dynamique la quantité de serveurs (frontaux web dans ce cas) gérant les requêtes de recherche (qui ne devaient pas être si compliqué que cela) à la charge réelle.

Un hébergement dans une plateforme de type Windows Azure aurait en effet permit en quelques clics (et quelque minutes de déploiement) d’augmenter le nombre de frontaux web; et ce soit en anticipation (dès le samedi par exemple), soit de manière dynamique au fur et à mesure de la journée (en fonction de l’état de charge des instances déjà déployées via un monitoring).

 

La prise en compte des contraintes des architectures élastique dans la conception de la page de recherche n’aurait engendrée aucun couts de développement supplémentaire vu la simplicité de la fonction de recherche à implémenter.

Le surcout lié à l’utilisation des ressources du cloud pendant une courte durée aurait été imperceptible par rapport au cout d’organisation d’une telle journée de vote, et – de toute façons – inférieur aux couts développement (à perte) d’un site non évolutif qui n’a pas rendu son service.

A titre d’information, sur la base des couts unitaires de la plateforme Azure, le cout de 10 instances “small” pour 24h aurait été de 24*10*0.0852€ht, soit 20,448€ht (http://www.microsoft.com/windowsazure/fr/fr/pricing/).

A contrario, l’incapacité pour un potentiel votant de trouver facilement son bureau de vote, ou l’image négative véhiculé par un site critique qui ne tient pas la charge et ne rend pas le service attendu aura surement un impact beaucoup plus important.