La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Indisponibilité d’Amazon EC2
• Coherence 3.7 – Plus de problèmes de large heap

Le coin de la technique

• Sortie de Hudson 2.0
• CXF 2.4.0 est dans les bacs

Actualité éditeurs / SSII

Indisponibilité d’Amazon EC2

Jeudi dernier, Amazon a connu un gros problème de disponibilité de ses serveurs situés dans certaines régions des Etats-unis, perturbant très fortement des sites connus comme Quora, FoursQuare ou Reddit. Cette annonce a déjà été beaucoup commentée, les sceptiques du modèle de cloud computing y voyant la preuve de la méfiance qu’il faut accorder à ces nouveaux services. Il est évident que ces perturbations laisseront des traces pendant longtemps. Que dire par exemple de l’histoire de ce fournisseur d’accès qui, après avoir beaucoup hésité, a mis 6 mois pour migrer et qui a justement fini la migration la semaine dernière ?

On peut néanmoins affirmer qu’Amazon joue assez bien la transparence comme l’attestent les nombreux blogs sur le sujet ainsi que leur page très bien faite sur les statuts de leurs services dans le monde entier. Par ailleurs un autre site permet de voir le statut actualisé des sites impactés.

De plus, comme le souligne ce blog, les torts sont partagés avec les clients d’Amazon qui n’ont pas toujours tenu compte des avertissements de la compagnie, comme le souligne un des responsables d’EveryBlock:

While the acute problem originated with AWS, EveryBlock is not without blame for this downtime. Frankly, we screwed up. AWS explicitly advises that developers should design a site’s architecture so that it is resilient to occasional failures and outages such as what occurred yesterday, and we did not follow that advice.

Sans surprise ce sont les projets ayant le plus tenu compte des avertissements d’Amazon qui s’en sont le mieux sortis. Netflix en est un bel exemple et les 5 leçons qu’ils ont tirées de leurs précédentes expériences sont à méditer. La 3ème leçon, entre autre, est savoureuse: The best way to avoid failure is to fail constantly. Pour cela ils ont mis en place un ensemble de scripts qu’ils ont nommé Chaos Monkey et qui consiste à tuer des instances au hasard afin d’éprouver leur système en permanence.

Coherence 3.7 – Plus de problèmes de large heap

Coherence, la In Memory Data Grid d’Oracle, était comme beaucoup de ses consoeurs minée par le problème de la taille des JVMs.
Alors que les serveurs d’entrée de gamme embarquent 32 Go de RAM pour un prix dérisoire, nos grilles mémoires nous recommandaient laborieusement des heap de 1.5 Go à cause des problèmes de temps de pause du garbage collector. Coherence a pris le taureau par les cornes et suivi le même chemin que Terracotta Big Memory pour ne citer qu’eux : implémenter un memory manager à l’intérieur de la heap. Schématiquement, Coherence alloue au démarrage de la JVM un gigantesque tableau de _byte_ et gère lui même cet espace de stockage. Coherence annonce que nous pourrons désormais utiliser des JVM de 30 Go au lieu des limitations à 2.5 – 2 Go actuelles. Les simplifications seront très nombreuses (nombre de processus et de fichiers de logs à monitorer, sizing des data source / connections JMS utilisées en « write-behind », etc).

Autre innovation plus avant-gardiste qui ne concernera aujourd’hui que peu d’utilisateurs : le support de disques SSD, principalement pour porter les replicas. Enfin une rencontre avec Cameron Purdy, directeur technique de Coherence, pour un projet pour une grande banque parisienne, nous a appris qu’il travaille au support d’Infiniband pour connecter les noeuds d’une grille. Un Coherence 4 à 100 Gbit/s réels ?

Revenons à des cas d’utilisation de la vraie vie, le support de large heap est une grande simplification de mise en oeuvre (plus visible du côté Ops que du côté Devs) et nous avons encore plein d’attentes :

• Des API plus simples et de plus haut niveau (similaires à « JPA ») pour les équipes informatiques « normales » qui ne sont pas composées que de « geeks passionnés » ; même si ces API seraient plus contraignantes que l’API Map & POF actuelle,
• réplication inter-grille avec API de reconciliation (au hasard Londres, New York ou Tokyo pour les banques ),
• outillage de déploiement avec un modèle de packaging (similaire à nos .war) et un système de gestion centralisé de grille (déploiement, monitoring, etc).

Tous les détails sur InfoQ – Oracle Coherence 3.7′s Elastic Data Offers Transparent Overflow from Memory to Solid State Storage.

Le coin de la technique

Sortie de Hudson 2.0

Une nouvelle version majeure du serveur d’integration continu Hudson vient de sortir. Cette nouvelle version 2.0.0 introduit un changement dans la numérotation, en suivant le schémas majeur.mineur.patch, notamment préconisé par le versioning dans OSGi. Il se démarque désormais de la notation en 1.x ({{x}} étant le numéro de build), toujours utilisée par Jenkins.

Plusieurs nouveautés importantes accompagnent cette nouvelle version avec notamment une modification du système de plugin qui repose maintenant sur le conteneur OSGi Sisu, utilisé dans Nexus et Maven3. Ce framework reposant sur Google Guice, il permet l’utilisation des annotations de la JSR330 comme @Inject permettant l’injection de dépendances ou encore @Singleton assurant l’unicité d’une instance d’un bean. Sisu permet aussi l’injection de services OSGi sans avoir à écrire du code spécifique à OSGi.

Hudson reposant principalement sur des plugins, l’utilisation d’OSGi pour les déployer paraît particulièrement pertinente.
Ce nouveau système de plugin reste rétro-compatible avec les plugins Hudson actuels, mais la migration des plugins vers le nouveau système est cependant encouragé.

Jenkins devrait lui aussi supporter le JSR330 dans un avenir proche, permettant ainsi de supporter les plugins migrés. Certaines parties de l’implémentation proviendront directement des développements d’Hudson.

Outre cette importante nouveauté, cette nouvelle mouture apporte quelques fonctionnalités supplémentaires :

• des boîtes de dialogue modales de confirmation,
• la possibilité de nettoyer le workspace avant chaque build,
• l’amélioration du support de maven,
• la possibilité de publier les plugins Hudson dans un dépôt maven.

Il semble donc que la communauté Hudson soit particulièrement active et qu’une saine concurrence soit installée entre Jenkins et Hudson.

CXF 2.4.0 est dans les bacs

La version 2.4.0 de CXF vient de sortir.

Cette nouvelle version apporte de nouvelles fonctionnalités dont :

• des améliorations au niveau de WS-Security avec le support des tokens SAML2, de meilleures performances et un meilleur support de la partie sécurité du profile WS-I Basic,
• databinding JiBX,
• des améliorations pour la transformation des messages XML pour JAX-RS,
• l’ajout d’une console permettant l’accès aux logs CXF,
• l’amélioration du support OSGi, permettant le déploiement de CXF dans un conteneur OSGi comme Apache Karaf,
• une amélioration du temps de démarrage et de l’empreinte mémoire.