Compte-rendu des Rencontres Spring 2008

Pourquoi Spring ?▲

Connaissez-vous SpringSource ?▲

SpringSource rachète G2One▲

Orateur : Peter Cooper-Ellis
Fonction : SVP Engineering at SpringSource

Avant de rejoindre SpringSource, Peter Cooper-Ellis a travaillé chez Bea et c'est à lui qu'on doit la réussite du serveur d'application Weblogic. En tant que Vice-président of Engineering and Product Management, il s'occupe évidemment de la gestion des produits de SpringSource.

De ce fait, il est venu nous présenter ceux-ci qu'il classe en trois catégories :

• Développement : portfolio, STS, modèle de programmation Spring, Groovy/Grails
• Déploiement : SpringSource Entreprise, SpringSource ERS, SpringSource Dm Server, Performance Pack
• Support : SpringSource AMF, abonnement au support, formation et consultance

A coté de la partie marketing, la roadmap non définitive de fin 2008 / 2009 nous a été présentée :

• Fin 2008
  • Spring .Net 1.2
  • Spring Integration 1.0
• 1er trimestre 2009
  • Spring 3.0 (REST, EL, Java 5)
  • Spring DM 1.2
  • Spring IDE 2.5
  • Groovy 1.6
  • Grails 1.1
• 2ème trimestre
  • Spring Dm 2.0 (RFC 124)
  • Spring Batch 2.0
  • Spring ROO
  • Spring Security 2.5
  • Spring Web (Flex)

Téléchargez les slides de la présentation (pdf)

Orateur : Mark Thomas
Fonction : Un des principaux contributeurs du projet Apache Tomcat

Ce fût ensuite au tour de Mark Thomas de prendre la parole. Cette conférence fût des plus intéressantes, même si, une fois n'est pas coutume, elle était plus à destination des administrateurs système que des développeurs.

Mark Thomas est l'un des principaux commiters du projet Apache Tomcat. Il a résolu plus de 1500 bugs dans celui-ci sur une période de 5 ans.

Avant de rentrer dans des moyens concrets pour tuner Tomcat, Mark a tout d'abord voulu expliquer le processus à suivre pour détecter et corriger un goulot d'étranglement :

1. Bien comprendre l'architecture du système
   Autrement dit, savoir ce que l'on teste, connaître les différentes ressources.
2. Stabiliser le système
   Ne pas modifier le code durant la phase de tuning, car cela peut engendrer des effets de bords qui invalideront les résultats
3. Se donner des objectifs clairs
   Il est primordial de savoir ce que l'on cherche à atteindre pour une application, afin de piloter l'optimisation dans le bon sens.
4. Mesurer les performances actuelles
5. Identifier le goulot d'étranglement courant
   Il peut y avoir plusieurs goulots, mais il ne faut travailler que sur le plus important
6. Fixer la cause du problème
   .. et pas les symptômes.
7. Répéter le processus jusqu'à atteindre les objectifs fixés

Mark a ensuite présenté différents moyens d'améliorer les performances de Tomcat.

Le premier point porta sur la gestion des fichiers de logs, la configuration par défaut n'étant pas optimale pour un environnement de production. La première optimisation consiste à élaguer la configuration afin d'écrire les logs uniquement dans des fichiers, exit donc la sortie sur la console, mais en ajoutant par ailleurs une rotation des fichiers afin d'éviter les fichiers de plusieurs Go.

Si cela est suffisant dans certains cas, dès qu'il y a beaucoup de traitements et donc beaucoup de traces écrites, un nouveau goulot d'étranglement apparaît : l'écriture sur disque. La solution, dans ce cas précis, est de passer sur du logging asynchrone. Autrement dit, les traces ne sont plus écrites directement sur disque mais stockées dans une pile mémoire. Celle-ci sera utilisée ensuite par un processus qui la videra en écrivant de manière optimisée sur le disque (écriture par bloc par exemple).

Il faudra cependant limiter la taille de cette pile afin de ne pas avoir de problème de surconsommation de mémoire. Si la capacité devait être atteinte, le logging redeviendrait temporairement synchrone.

Le gros point suivant que Mark présenta fût les différents connecteurs HTTP pour Tomcat :

• Java blocking IO
• Connecteur natif (APR)
• Java non-blocking IO

Le premier est le plus vieux de tous, et le plus stable. Cependant, il n'est pas toujours optimal. Il n'est pas des plus rapides pour les connexions SSL car il se base sur une implémentation Java (JSSE) de SSL.
Son autre point faible est le mode http Keep alive.

Pour rappel, sans ce mode, une connexion http fonctionne comme ceci :

• Ouverture connexion TCP
  • Envoi d'une requête HTTP
  • Réception réponse HTTP
• Fermeture connexion TCP

Autrement dit, pour chaque requête, une connexion TCP est créée et fermée, ce qui peut parfois être lent. Pour résoudre ce problème, un mode keep-alive permet de fonctionner autrement :

• Ouverture connexion TCP
  • Envoi d'une requête HTTP 1
  • Réception réponse HTTP 1
  • Envoi d'une requête HTTP 2
  • Réception réponse HTTP 2
  • ...
  • Envoi d'une requête HTTP N
  • Réception réponse HTTP N
• Fermeture connexion TCP

Dans ce mode, la connexion reste ouverte entre le client et le serveur pour N requêtes.
Mais le souci dans le connecteur IO bloquant, est qu'un thread est dédié à une connexion et qu'un nombre maximum de thread est fixé. Donc si ce nombre est X et que X clients se connectent en keep-alive, tous les threads sont utilisés et tout nouveau client se verra refusé.

Heureusement, le connecteur non bloquant résoud ce problème.
Par contre il utilise toujours l'implémentation JSSE, et donc reste moyennement performant pour les connections SSL.

D'où l'intérêt du connecteur natif. Celui-ci utilisant la librairie OpenSSL pour la gestion des connexions sécurisées, les performances sont bien meilleures. Il est tout aussi performant dans la gestion des connexions keep-alive.

Voici un tableau qui résume assez bien les cas d'utilisation de l'un ou l'autre connecteur

Mark a ensuite expliqué deux autres moyens d'optimiser les performances :

• Utilisation d'un cache pour les ressources
• Tuning de la JVM (Garbage collector, taille du heap)

Toujours dans la problématique des performances, il est ensuite passé sur un autre sujet intéressant, le loadbalancing ainsi que le clustering de Tomcat.

Concernant le load-balancing, toute la configuration est totalement gérée du coté d'Apache, et particulièrement le mod_proxy_http. Il faudra configurer celui-ci correctement afin de rediriger les requêtes d'une même session http vers le bon Tomcat. Pour cela, une table de routage se base sur le JSessionId qui est l'identifiant unique de la session.

Cette configuration est déjà très intéressante, mais en cas de panne d'un des serveurs Tomcat, toutes les sessions de celui-ci seront perdues. Pour résoudre cela, il est nécessaire de configurer un cluster. La configuration d'un cluster par défaut se résume à une ligne dans le fichier de configuration de Tomcat.

Mark a conclu sa conférence par une série de petites astuces et conseils. C'est ainsi qu'il recommande l'utilisation de Tomcat clustérisés durant la phase de développement si l'on sait d'avance que cela sera le cas en production. De nombreux problèmes pourront ainsi être traités dès le départ.

Téléchargez les slides de la présentation (pdf)

Orateur : Juergen Hoeller
Fonction : Leader du projet Spring

La conférence de Juergen Hoeller fût certainement celle la plus attendue de l'auditoire. Allions nous enfin avoir plus d'information sur la future nouvelle version de Spring ?
Et Juergen Hoeller à décider de faire durer le suspens !

Il a tout d'abord rappelé ce que la version 2.5 apporta :

• Configuration basée sur les annotations :
  • Propre à Spring : @Autowired, @Transactional, @Service,@Repository.
  • Mais aussi les standards : @PostConstruct, @PreDestroy, @Ressource, ...
• Nouveau support tout les tests
• Nouvelle API pour Spring MVC, elle aussi basée sur les annotations
• Nouvelle API pour le support des portlets
• ..

Après ce rappel, il a tout de même enfin parlé de Spring 3.0. Cette version nécessitera obligatoirement Java 5, mais reste compatible avec J2EE 1.4 et JEE 5.

Puis il présenta une des grosses nouveautés : les expressions languages.

Celles-ci permettront d'injecter dans un bean, une référence dynamique vers un autre bean, ou une propriété de celui-ci :

<bean id="monbeanA" class="test.monBeanA" init-method="initializeData"/>

<bean id="monBeanB" class="test.monBeanB">
	<property name="maPropriete" value="#{monBeanA.unePropriete}"></property>
</bean>

Dans cet exemple, la propriété " maPropriete " de monBeanB sera toujours la valeur de la propriété " unePropriete " de monBeanA. Le mot " toujours " a son importance.

Il était déjà possible d'injecter une valeur provenant de la propriété d'un autre bean grâce à la classe PropertyPathFactoryBean. Mais la différence, c'est que la valeur injectée était statique. Autrement dit, si durant l'exécution la propriété monBeanA.unePropriete changeait, la propriété monBeanB .maPropriete elle ne l'était pas. Les deux valeurs n'étant ainsi plus identiques.

Avec les EL, ce n'est plus réellement la valeur de unePropriete qui sera injectée dans monBeanB mais un proxy qui à chaque utilisation fera l'équivalent de ceci :

	Return applicationContext.getBean("monBeanA").getUnePropriete;

Au final, même si la valeur change dans le bean cible, les autres qui lui sont liés continueront de travailler sur la bonne valeur.

L'autre grosse nouveauté sera le support de REST dans Spring MVC. Le but de ce support est d'être intégré directement dans l'API de Spring MVC. Ce n'est donc pas un remplaçant de JAX-RS.
Différents formats de représentation seront possibles : JSON, XML ou ATOM.

Le support de la validation du modèle sera aussi ajouté. Les annotations de Hibernate Validators seront utilisables ainsi que les futures annotations de la JSR 303.

Celles-ci seront à la fois utilisées pour la validation, mais aussi par Spring MVC pour faire du rendu. Par exemple, l'utilisation de @ShortDate sur un champ de type date aurait comme conséquence que ce champ s'afficherait sous forme de date, sans l'heure, automatiquement.

Spring 3.0 apportera aussi le support de Portlet 2.0.

Concernant la roadmap, Spring 3.0 M1 était annoncée pour fin novembre mais fût légèrement en retard pour être livrée dans le panier de Saint Nicolas.
Spring 3.0 RC1 quand à elle est prévue pour Mars 2009 et la version finale pour Avril 2009.

Téléchargez les slides de la présentation (pdf)

Les conférences se clôturèrent comme prévu par une table ronde avec des grands utilisateurs de Spring.
Durant celle-ci, nous avons pu voir que le framework est utilisé dans divers domaines et sous diverses formes.

Que ce soit comme fondation d'un framework 'maison', que ce soit dans un environnement temps réel ou encore dans des applications à très haute charge, Spring trouve toujours sa place.
Son utilisation étant souvent synonyme de gain et de meilleure qualité de code.

Une question intéressante fût celle concernant Spring dm Server. Didier a en effet demandé aux utilisateurs présents si ce serveur serait potentiellement utilisé ou non.
Certains étudient clairement la solution (SGCIB) car la possibilité de recharger à chaud un module sans devoir stopper l'application est très intéressante.

Mais il en ressort qu'il va être assez difficile de faire comprendre aux 'décideurs' en quoi l'investissement est intéressant.