Revue de Presse Xebia

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

Actualité éditeurs / SSII

• Java 7

Le coin de la technique

• Migration 30 Petabytes sur Hadoop pour Facebook
• Joda-Time à l’heure de la 2.0

Actualité éditeurs / SSII

Java 7

Ca y est, après une longue attente, Java 7 est sorti la semaine passée, le 28 juillet pour être exact. C’est sous la forme d’OpenJDK, le pendant open-source de l’ancien JDK fermé de Sun qui était jusqu’aux versions 6 l’implémentation de référence, que s’effectue cette sortie.
Nous vous avons tenu au courant assez régulièrement de l’avancement des travaux donc nous ne reviendrons pas en long, large et travers sur tout ce qu’apporte cette version et sur sa gestation pas toujours facile. Alors bien sûr, certains regretteront l’absence des expressions lambda et du projet Jigsaw (modularité) reportés à Java 8, mais ne boudons pas notre plaisir et profitons:

• du fork/join
• la fermeture automatique des ressources auto-closables
• du support des Strings dans les switch
• du support du symbole underscore ‘_’ dans les nombres comme séparateur, pour une meilleure lisibilité
• du multi-catch d’exceptions
• de l’opérateur diamant apportant une meilleure inférence de type sur la création d’instances génériques
• de Nio 2 (que nous vous avons récemment présenté) et de ses améliorations sur les E/S: l’ajout des Path du service Watchable ainsi que le support des symlinks pour le filesystem, mais aussi de nombreux apports sur les E/S asynchrones et les sockets non bloquants.
• invokedynamic, qui devrait accélérer les langages dynamiques qui l’utiliseront

Premiers couacs

Mais comme toute nouveauté, cette nouvelle version du JDK apporte aussi son lot de douleurs. Apache l’a compris avec un bug sur les projets d’indexation et de recherche Lucene et Solr. Après mise à jour vers le JDK 7, des indexes se sont corrompus et des JVM sont tombées par dizaines avec l’erreur la plus connue des étudiants qui commence en langage C: SIGSEGV ou Segmentation Fault !

Les erreurs se portent sur une partie identifiée du projet, l’algorithme Porter Stemming pour l’optimisation de son moteur de recherche dans la langue de Shakespeare. La réponse apportée par l’équipe d’Apache ne s’est pas fait attendre. Après un premier problème d’optimisation des boucles, des effets de bords des nouvelles locales dans le JDK ou encore avec DataInput.readVInt(). Le premier fix est d’utiliser le paramètre de VM *XX:-UseLoopPredicate.*

Pour Solr, le problème venait principalement du fait que la bonne exécution des tests était dépendantes de l’ordre dans lequel ils étaient écrits. Comme quoi, les principes de réalisations des tests unitaires ne sont pas vains !

Il n’en faut pas moins pour que la blogosphère ne s’enflamme en quelques temps, dans des invectives contre JDK 7 et Apache, à tort. En effet, le problème vient plus d’un bug d’implémentation de HotSpot plutôt que des JSR en elle-mêmes. Le conseil est donc d’utiliser le workaround pour les projets Solr et Lucene, et d’attendre le bug fix d’Oracle. Oracle tente de rassurer les foules par ce billet: les corrections de bug des JVM sont en cours.

Le coin de la technique

Migration 30 Petabytes sur Hadoop pour Facebook

Dans les architectures distribuées de stockage de données, une nouvelle fait le buzz cette semaine. Quand Facebook décide de déplacer ses datacenters, évidement, il y a de l’octet qui se promène. Victime de son trafic, l’ancien datacenter prévu initialement pour 10 PB a atteint dernièrement les 30 PB (avec pas moins de 10 PB généré en une seule année), soit quelques 30 000 000 Go!

Hadoop est le célèbre framework d’Apache pour la gestion de filesystem distribué. Il est utilisé par Facebook pour la gestion interne d’analyse ainsi que les produits additionnels (comme Facebook Ad Network), avec Hive pour la gestion d’un datawarehouse.

Voilà un potentiel sujet pour un prochain challenge USI: comment déplacer 30 PB de filesystem avec une contrainte d’exploitation du système en 24/7, et quelques millions d’utilisateurs de connectés ? (avis aux amateurs de défis !)

Côté infrastructure, 1200 serveurs 8-coeurs ainsi que 800 serveurs 16-coeurs avec chacun 12 To et 32 Go de RAM.

Pour répondre à cette problématiques, les ingénieurs optent pour la solution du basculement total de l’ancien cluster vers le nouveau. Transporter un tel volume de données n’est pas instantané. L’équipe a du développer un système de réplication des changements en continue de l’ancien cluster vers le nouveau, tant que le basculement n’était pas effectué.

L’ajout d’un plugin sur Hive permet d’écrire tous ses changements sources dans un fichier d’audit. Le système de réplication est branché sur ce fichier et reproduit en continu les changements sur le nouveau noeud. Ce système n’est pas sans rappelé le mécanisme Change Data Capture d’Oracle !

Ensuite, l’équipe s’enferme dans une war-room, tire à la courte-paille quel ops devra lancer la commande fatidique, et stoppe l’ancien cluster. Je vous laisse imaginer la petite émotion lorsque le bouton Enter du clavier est pressée. Une fois le tour de magie effectué, et le sanity check passé, un changement de DNS ensuite permettra de rentre le système stable, et le stress des équipes redescendre face à la réussite d’un projet aussi colossal !

Ceci est par ailleurs une excellente publicité faite à Hadoop et Hive pour l’intégration dans le monde de l’entreprise.

A titre de comparaison, le nouvel accélérateur à particules du CERN, le LHC bat des records de collisions. Ses chiffres pourtant prodigieux n’arrivent que difficilement à la hauteur des volumétries de Facebook. Avec plus de 10 000 milliard de collision par an, et plus 1 Mo de données par collision, on atteint la barre des 10 Po par an. Cependant, on ne mesure pas l’octet à la valeur qu’il peut représenter.

Joda-Time à l’heure de la 2.0

La gestion des Date et Calendar dans le JDK étant ce qu’elle est, nombre d’entre nous s’appuient régulièrement sur la bibliothèque Joda-Time. Celle-ci fournit nombre de classes permettant de gérer tout ce qui tourne autour des dates, heures et calendriers. Joda est d’ailleurs la référence en la matière sur laquelle s’appuie grandement la JSR 310 qui est, aux dernières nouvelles, attendue pour Java 8.
Mais Java 7 venant à peine de sortir, ne nous emballons pas et profitons de la sortie de Joda-Time 2.0. Stephen Colebourne l’annonce sur son blog, cette version n’a vraiment rien de révolutionnaire. Et c’est d’ailleurs le but: améliorer la version précédant (1.6.x) tout en restant compatible avec la grande majorité des utilisations. On note par exemple un passage à Java 5 avec utilisation des génériques pour quelques classes, la suppressions de classes flagguées comme @Deprecated depuis longtemps ainsi que de nombreuses petites améliorations listées sur le changelog officiel. Au final, ce changement de digit n’apporte rien de fondamental, mais tout comme pour le récent Linux 3.0, mettre à jour son noyau ou ses librairies dans la nouvelle version en “.0“ procure toujours son petit moment de plaisir. Ne dites pas le contraire, je sais que pour vous aussi :-)