Revue de Presse Xebia

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

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Les JUGs leaders s’occupent de nous

Le coin de la technique

Sortie de Tapestry 5.2

Tapestry est passé à la version 5.2. Depuis la semaine dernière, vous pouvez utiliser la version beta 5.2.1 dont la release sera bientôt disponible. Cette fois, l’équipe n’a pas respecté le planning d’une version tous les 4-6 mois, mais a préféré attendre 14 mois pour que cette version majeure voit enfin le jour. Cette version 5.2 apporte des fonctionnalités et innovations significatives pour les performances et la productivité de développement. Elle a également été marqué par des évènements d’importance pour le projet et la communauté.

Tout d’abord, son créateur Howard Lewis Ship (nommé java champion cette année) a repris le statut de consultant indépendant. Ainsi, il a eu la liberté d’intégrer au fil de l’eau la version 5.2 au sein de deux grosses applications, ce qui a mis l’équipe sur la piste de nouveaux besoins et correctifs. D’autre part, au cours de l’année, de nouveaux committers (dont deux français) ont intégré le projet, de nouveaux membres PMC (Project Management Committee) ont été nommés, et de nombreuses contributions ont été apportées.

Tout en respectant la compatibilité ascendante, voici les fonctionnalités les plus importantes qui ont été ajoutées :

L’amélioration du rechargement à chaud: Grâce au rechargement à chaud des pages et des composants, la productivité du développeur est l’un des principaux atouts de Tapestry. Avec la version 5.2, les services d’IoC sont aussi rechargés à chaud, ce qui permet par exemple au développeur de déboguer en live ses requêtes SQL.

JSR-303 Bean Validation: L’intégration avec l’API Bean Validation a été réalisée. Celle-ci permet maintenant d’utiliser les annotations JSR-303 directement dans les pages, les composants et les entités.

Composants, Mixins, Évènements, Meta-Programming: De nouvelles annotations ont été développées pour les utiliser dans l’IoC et faciliter d’avantage l’accès aux paramètres de la request et de la session http. Maintenant, il est encore plus facile d’étendre les fonctionnalités des composants et services via des annotations.
De nouveaux composants et mixins qui améliorent l’intégration avec javascript, la gestion d’erreurs, et la gestion des évènements ont été ajoutés au socle. De plus, de nouveaux événements pour le rendu des liens et des pages sont désormais déclenchés pour offrir encore plus de souplesse au développeur.

Standard SAX: Tapestry n’utilise plus le parseur StAX, il a été remplacé par le standard SAX. Ceci élimine tous les problèmes d’incompatibilité avec Google App Engine et les environnements OSGi que l’on pouvait rencontrer avec les versions précédentes.

Nouvelle API de réécriture URL: Jusqu’à la version 5.1.0.1, Tapestry offrait un support de premier niveau pour la réécriture des URL fondé sur le service URLRewriter. Ce service a été déprécié pour LinkTransformer qui permet d’adapter facilement les URLs existantes et à venir.

Les pages deviennent des singletons: Le pool de pages est maintenant déprécié sans aucun impact sur le code des applications. Désormais, les pages sont des singletons partagés entre threads, et les valeurs mutables sont stockées dans une Map clé-valeur qui appartient à chaque thread. Ce changement de stratégie implique encore moins d’utilisation mémoire, on peut donc espérer une amélioration des performances pour certaines applications.
En cas de besoin, le pool de pages peut être réactivé et monitoré grâce au support JMX (Java Management Extensions).

Documentation: La documentation est devenue un point prioritaire. Ainsi, pour vous mettre l’eau à la bouche, voici l’aperçu de la prochaine documentation du projet.

Pour finir, un nouveau livre Tapestry 5 est en cours d’écriture. Igor Drobiazko, nommé PMC du projet en début d’année 2010, auteur du livre en allemand Tapestry 5: Die Entwicklung von Webanwendungen mit Leichtigkeit! et évangéliste Tapestry (Jazoon 2010, plusieurs conférences en Allemagne en 2009 et 2010), travaille sur la rédaction d’un nouveau livre (en anglais) qui sera publié début 2011.

MongoDB et Foursquare

InfoQ revient sur les raisons de la panne récente de plus de onze heures du site Foursquare le 4 octobre. Le site, réseau social qui a grossi très rapidement (jusqu’à trois millions d’utilisateurs en août 2010), utilise la base de données NoSQL MongoDB.
L’indisponibilité a été la conséquence directe d’une forte montée en charge dans la base de données MongoDB que leur système de monitoring n’a pas été capable de détecter.

L’architecture de base: Le système affecté, pour des raisons techniques particulières, se compose d’un espace de travail en mémoire de la même taille que celle de la base de données. Donc, si la taille de la base de données dépasse la quantité de RAM disponible, le système tombe.
Leur première instance, un EC2 (_Amazon Elastic Compute Cloud_) de 66GB RAM dont la capacité a été dépassée, a été migrée sur deux nœuds de 66 GB RAM et une réplication de données dans un noeud esclave. Au moment de la migration, chaque nœud stockait 33GB de données, avec une configuration qui assurait que toutes les données d’un utilisateur se trouvaient toujours sur le même nœud.

MongoDB en panne: Les instances ont continué de croître, de façon déséquilibrée, ce qui s’explique par l’activité plus intense d’un certain nombre d’utilisateurs. Lorsqu’un fragment de données dépasse les 200 MB, MongoDB le découpe en deux de 100 MB. Au bout d’un certain temps une partition avait 50 GB et l’autre dépassait les 66 GB, donc la quantité de RAM disponible, et le système est tombé.
Lors d’une intervention d’urgence, l’équipe a ajouté un troisième nœud à la base, pour y transférer 5% des données du nœud en surcharge, afin de garantir la RAM requise dans l’ensemble du système.
Or le problème de performance n’a pas disparu. L’équipe a finalement constaté que la cause réelle de la panne était la fragmentation des données sur disque dans le nœud 0. Effectivement 5% de données ont été transférés, mais la taille des données (les checkins de Foursquare) sont d’environ 300 octets alors que la pagination se fait sur des zones de 4ko. Le déplacement des données n’a donc quasiment pas eu d’effet sur la fragmentation et le problème a persisté.
Finalement, l’équipe de FourSquare a dû compresser la base de données complète, opération qui ne peut être fait qu’en mode offline. Ceci a duré quatre heures de plus, soit onze heures au total, et aucune donnée n’a été perdue.

La suite: Après l’incident, l’équipe a ajouté des nœuds dynamiquement pour y distribuer uniformément les données. A présent, le système utilise 20GB pour chaque partition. Foursquare reste fidèle à la solution MongoDB.

Conclusions: Si on arrive à capacité maximale, il est très compliqué de s’en sortir sans arrêter le système quand les objets sont de petite taille. Or, si le problème est anticipé, en ajoutant des nœuds dynamiquement, le système pourra scaler sans tomber. Il apparaît maintenant évident que pour bien anticiper, il faut impérativement mettre en place le système de monitoring approprié, ce qui n’était pas le cas.

Selon un expert du W3C, HTML5 n’est pas prêt pour la production.

Philippe Le Hégaret, expert au W3C, confie, via deux interviews, sur InfoQ et InfoWorld, sa vision de HTML5 à l’heure actuelle : c’est une technologie utilisée par des early adopters, qui doivent s’en servir pour fournir du feedback, et qui ne sera pas prête pour la production avant fin 2011 début 2012.
Philippe Le Hégaret base son analyse sur le manque d’interopérabilité de HTML5 sur les différents navigateurs. Alors que seulement 90 tests de compatibilité sont d’ores et déjà disponibles (et plus de 900 en attente de validation), on constate déjà des différences de fonctionnement selon la plateforme d’exécution. Il est, selon lui, impensable de passer en production une technologie si peu standardisée. Le chantier de standardisation devrait grandement avancer en mai 2011, qui est la date butoir pour le Last Call document du W3C.
Les adeptes des (fantastiques) démonstrations 2D, 3D et videos en HTML5 verront dans cette annonce la volonté forcenée du W3C de tout standardiser avant de passer en production. D’autres (peut-être les « anciens »), qui ont vécu la grande guerre Netscape – Internet Explorer des années 90, y verront une forme de sagesse.

Actualité Northscale / Membase / Memcached

Vous connaissez peut-être déjà Memcached le serveur de cache développé par la société Northscale. Après l’annonce en juin d’une nouvelle offre NoSQL nommée Membase, l’éditeur avait rendu disponibles les sources via un projet open source. La solution Membase a été développée comme une extension au serveur Memcached. Membase est donc compatible avec les clients Memcached tout en ajoutant à la solution:

La persistance des données
La distribution et la réplication des données sur les nœuds du cluster Membase
L’ajout et la suppression de nœuds à chaud
Une interface d’administration et de supervision du cluster

A l’occasion de la sortie officielle de la version finale 1.6.0, l’éditeur a même changé de nom. Le nouveau nom Membase Inc, reflète clairement la volonté et la nouvelle orientation de la société.
Une nouvelle n’arrivant jamais seule, la conférence Hadoop World fût l’occasion pour Cloudera d’annoncer l’intégration de la solution Membase à son offre Cloudera’s Distribution for Hadoop. L’intégration est possible de deux façon différentes:

Un module Membase permet d’envoyer le flux de données en temps réel sur CDH.
Un utilitaire de chargement par batch permet de transférer les données dans un sens ou dans l’autre.

Pour plus d’information sur le sujet:

Evènements de notre communauté en France et à l’étranger

Les JUGs leaders s’occupent de nous

Antonio Goncalves vient de nous gratifier d’un long article sur le blog du Paris JUG. Dans une première partie, il revient sur l’inquiétude naturelle de la communauté à la suite du rachat de Sun par Oracle. D’autant qu’à l’époque de Sun, les JUGs étaient assez libres, alors qu’Oracle semble plus encadrer les choses. Il joint ensuite une copie du mail (co-écrit avec 4 autres JUG leaders) qu’il a envoyé à la communauté mondiale des JUG leaders. Ceci fait suite à la participation des 5 auteurs au Meeting Oracle EMEA (Europe, Middle East and Africa).
Avant tout, ils notent que Sun n’organisait pas de telles rencontres. Bon point pour Oracle ! Ensuite, même si l’on sent que les JUG leaders ont pu être un peu déboussolés dans une telle manifestation, qui comportaient aussi des Oracle User Groups Leaders et un MySQL UG Leader, ils ont vite repris du poil de la bête en sachant structurer et formaliser leurs pensées, craintes et questions. Avec par exemple une volonté affirmée de créer des synergies entre les JUGs. On devine aussi une certaine envie de marquer l’appartenance à la communauté Oracle (OUGs) tout en préservant leurs origines (JUGs). Enfin, et ce n’est pas le moins important, nos leaders veulent se structurer pour être visibles d’Oracle. La notion de poupée russe est même utilisée pour illustrer la hiérarchie des User Groups, devant assurer le maintien de la cohésion entre Oracle et sa communauté Java.
Au final, même si tout n’est pas encore défini et clair (notamment sur les prérequis pour participer à l’ International Oracle User Group Community ,IOUC, qui nécessiterait d’être client ou partenaire d’Oracle, un comble pour les Javaistes), les JUGs leader semblent confiants. Mais ne se gênent pas pour avertir Oracle que pour eux, c’est toute la communauté Java qui doit être prise en compte, avec ses sous-communauté diverses comme Android, Spring, Groovy/Grails, Scala… Quel que soit nos centres d’intérêt en Java, on peut donc être rassurés : nos 5 mousquetaires-JUGs-leaders ont pris soin de nous et ont prévenu Oracle : Java, c’est une communauté pour toutes et toutes pour une, pas autrement !