N’avez-vous jamais eu besoin de recharger un fichier placé dans l’un des répertoires apparaissant dans la variable d’environnement CLASSPATH ? Habituellement, ces fichiers sont chargés dans la mémoire de la JVM en utilisant la méthode "getResourceAsStream" de la classe "java.lang.ClassLoader". Or, une fois les fichiers chargés par un ClassLoader, ils restent en mémoire et ne sont plus lus depuis les disques ou le réseau. Pour forcer leur rechargement, il suffit d’instancier un nouveau ClassLoader. Cela se fait en quelques lignes de Java :

      
public class ResourceLoader {
        public static InputStream getResourceAsStream(String name) {
          ClassLoader loader = new URLClassLoader(constructUrls()) {
            public URL getResource(String name) { return findResource(name); }
          };
          return loader.getResourceAsStream(name);
        }

        private static URL[] constructUrls() {
          String classpath = System.getProperty("java.class.path");
          String[] paths = classpath.split(File.pathSeparator);
          int length = paths.length;
          URL[] arrayOfUrls = new URL[length];

          try {
            for (int i=0; i<length; i++)
              arrayOfUrls[i] = new File(paths[i]).toURI().toURL();
          }
          catch (MalformedURLException e) { ... }

          return arrayOfUrls;
        }
      }

Ippon Technologies organise la première formation en France autour de Mule ESB du 09 au 11 juin à Boulogne Billancourt.

Cette formation sera animée par Antoine Borg, formateur de Ricston (la société de formation de Ross Mason), qui est notamment en cours de rédaction du livre “Mule 2: Official Developer’s Guide to ESB and Integration Platform”.

Pour une première nous avons choisi un angle architecture pour ce cours de 3 jours : Concepts ESB, Architecture de Mule, Best practices de Design, Sécurité, Performances,…

Le descriptif complet est accessible sur le site de Ricston.

Antoine couvrira les versions 1.x et 2.x de Mule aussi bien en OSS qu’en version Entreprise.

Le cours sera majoritairement en anglais sur support anglais même si Antoine a de bonnes bases de français.

Tarif : 1 490 Euros HT les 3 jours (repas et supports de cours inclus) – financement éligible au budget formation.

Pour s’inscrire : Jérémie Ballais – jballais@ippon.fr – 0146124848

Récemment en mission chez un acteur majeur du marché de l’énergie français, j’ai été confronté à un problème de performance sur l’un de leurs portails Web. Le symptôme était le suivant : lors de montées en charge, sur l’environnement de production, les temps de génération de certaines pages s’accroissaient dramatiquement (jusqu’à 12 secondes). Brièvement, les composants techniques constituant le portail sont les suivants :

  • un cluster de trois serveurs Apache,
  • un cluster de trois serveurs Weblogic Portal 8.1sp5,
  • un cluster .de trois serveurs Weblogic Integration 8.1sp5,
  • un connecteur iWay Adapter for SAP 5.5.006.R2, de iWay Software, installé sur chaque instance WLI,
  • SAP,
  • Oracle 9i.

L’environnement de production était dépourvu d’outil de diagnostic et aucun message d’erreur suspect n’apaisait dans les différents fichiers de traces.

Premiers réflexes :

  • Vérifier la charge des processeurs des serveurs Solaris. La charge des CPU était très faible.
  • Vérifier les accès aux entrées/sorties. Le volume de données lues et écrites était très faible ainsi que le nombre d’accès aux disques et aux réseaux.
  • Vérifier l’activité du ramasse-miettes des différentes JVM depuis les consoles d’administration Weblogic. Rien à signaler.

Nous pouvions exclure les erreurs de programmation entraînant des surconsommations de CPU et d’I/O, les boucles infinies, et les fuites-mémoires de l’ensemble de nos hypothèses. Le ralentissement semblait être lié à un problème d’accès à une ressource critique tels que un pool JDBC, un pool de threads ou un bloc synchronisé.

Deuxièmes réflexes :

  • contrôler le nombre et l’activité des threads au travers des consoles Weblogic,
  • générer un “Thread Dump” en lançant un signal SIGQUIT (“kill -3” sous Unix ou “Control+Pause” sous Windows) à destination des processus exécutant les JVMs. Pour rappel, cette opération ne termine pas l’exécution des JVMs. Lorsqu’une JVM reçoit ce signal, elle suspend momentanément l’exécution de toutes ses threads, génère une trace d’exécution (“stack trace”) pour chacune d’elles, puis les réactivent.

L’outil idéal pour analyser un “Thread Dump” est … “Thread Dump Analyzer”. Il s’agit une application gratuite disponible à l’adresse : http://tda.dev.java.net

Premier constat : près de la moitié des threads des serveurs WLI étaient en attentent sur le même bloc synchronisé. Le point de contention était localisé dans la méthode “debug” appartenant à la classe “LoggerDecorator” du connecteur iWay.

Pour aller plus en avant dans nos investigations, nous avons installé le produit Introscope de CA | Wily Technology sur les serveurs WLI de l’environnement de qualification, puis nous avons généré du trafic afin de reproduire l’anomalie. Introscope est un outil de supervision et de diagnostic permettant de suivre l’activité de tous les composants sollicités durant une transaction, sur plusieurs serveurs. Son faible surcoût en ressource machine permet de le déployer sur des environnements de production.

Deuxième constat : 92% du temps de production des pages du portail était consommé par le mécanisme de trace (log) du connecteur SAP !!

Ne disposant pas des sources du connecteur iWay pour le corriger, un cas a été ouvert auprès de BEA Systems.

En conclusion,

  1. TDA nous a permis de cerner la source du problème. Ce petit outil gratuit doit faire parti de votre trousse de secours.
  2. Instroscope nous a permis d’identifier la méthode générant les ralentissements et de mesurer leurs importances. Cet outil nous a également permis de corréler les ralentissements avec les accès simultanés à la classe de trace en superposant la courbe des temps de réponse de la méthode incriminée et la courbe du nombre des accès à la méthode. Il s’agit d’un produit évolué permettant de superviser des applications complexes en production et de diagnostiquer rapidement les sources d’une anomalie.

Après de nombreux mois de développement secret, SpringSource a annoncé Mercredi dernier (30 avril) la sortie de la version Beta de SpringSource Application Platform : une plateforme d’hébergement d’applications orientée OSGi à 100%. (Rod Johnson considère que l’appeler un serveur d’application serait un peu réducteur 😉 : cf : http://java.dzone.com/news/interview-rod-johnson-springso )

Si la plupart des serveurs d’application JEE du marché passe à OSGi pour gérer le coeur de leur serveur, il ne semble pas que leur objectif soit de proposer sa puissance directement aux applications qu’ils hébergent. Avec S2AP, c’est tout le contraire : l’objectif est bien de développer et déployer des applications d’entreprises basées sur OSGi ; l’implémentation des specs JEE n’a pas été une contrainte (même si le profil web des specs JEE 6 sera certainement supporté).

Côté techno, au coeur de S2AP, on trouve SpringSource Dynamic Module Kernel (DMK) un noyau se basant sur Equinox (le containeur OSGi de la fondation Eclipse) et l’étendant pour fournir les bases de la plateforme. Un module Tomcat permet d’exposer des applications web.
Le tout étant bien sûr supporté par les frameworks Spring et Spring Dynamic Module for OSGi (Spring-DM)
La version 1.0 permet de déployer facilement trois types d’applications :
– les WAR standards
– des WAR allégés : où les dépendances sur les librairies sont spécifiés via les mécanismes OSGi plutôt que d’être inclus dans le répertoire WEB-INF/lib
– les PAR : Platform Archive : qui sont un ensemble de bundle OSGi formant un tout logique. Nouveauté par rapport à du OSGi standard : les PAR forment un scope application qui isole les éléments de chaque PAR des éléments des autres PAR.

Les ear ne sont pas supportés.
Pour faciliter la gestion des dépendances sur le mode OSGi, la plateforme maintient un repository de bundles OSGi.
Tout bundle OSGi standards peut être placé dans le repository est ainsi être disponible pour toutes les applications déployées.
SpringSource héberge un repository central où de nombreuses librairies open-source ont été OSGi-ifiées.

Pour faciliter l’utilisation de la plateforme, il est fortement conseillé d’utiliser les mécanismes de Spring Dynamic Modules pour créer les différents modules OSGi. Il suffit en particulier de placer les descripteurs d’assemblage Spring dans le répertoire /META-INF/spring/ du module et d’y utiliser le namespace osgi pour importer les services OSGi nécessaires au bundle ou exporter les services qu’il propose.

Les guide d’utilisateur et du programmeur de la plateforme :
http://static.springsource.com/projects/s2ap/1.0.0.beta/user-guide/html/
http://static.springsource.com/projects/s2ap/1.0.0.beta/programmer-guide/html/
bien que relativement courts, sont bien écrits et constituent de très bonne intro à l’utilisation de S2AP.

Je pense qu’il faudra regarder la doc de Spring DM en détail pour pouvoir utiliser tout le potentiel de la plateforme.

La plateforme s’installe facilement et est directement opérationnel.
Un effort particulier a été fait sur la gestion des logs du serveur (ils appellent ça la serviceability). Le log principal contient uniquement les stades importants du démarrage et du déploiement.
Tandis que des fichiers de traces logguent avec énormément de détail les actions réalisés sur les différents modules.
Une console d’admin est disponible. Mais pour le moment elle est limitée au déploiement/redéploiement des applications. (On notera qu’un répertoire pickup permet aussi les déploiements automatiques )

Les options du script de démarrage permettent d’activer facilement le support de JMX. Les nombreux MBeans de tomcat sont ainsi exposés. Pour le moment, les Mbeans spécifiques à S2AP sont liés au déploiement et à l’arrêt de la plateforme.

Une note d’implémentation sympa : S2AP privilégie le format JSON au format XML.
Ainsi la configuration est au format JSON et les dumps de diagnostique générés en cas d’erreur par S2AP sont aussi en JSON.

SpringSource fournit un plugin Eclipse pour faciliter le développement sur sa plateforme.
Le plugin Application Platform Tools est disponible librement, il peut s’installer sur un Eclipse 3.3 classique équipé de WTP et de Spring IDE 2.0.5 Beta. (Il n’est donc pas obligatoire d’utiliser SpringSource Tool Suite : la version d’Eclipse spécialement customisée par SpringSource)

L’intégration d’Eclipse avec S2AP est alors correct.
Un serveur S2AP peut être configuré dans Eclipse ce qui permet les déploiements automatiques depuis Eclipse (le redéploiement à chaud automatique est configuré par défaut à la moindre modification d’un élément d’un module)

Comme un projet OSGi classique développé sous Eclipse, le classpath est automatiquement mis à jour sur la base des différents imports OSGi spécifiés dans le manifest. Mais dans ce cas, le classpath référence les bundles installés dans le repository de l’installation de S2AP plutôt que les bundles du container Equinox inclu dans Eclipse.

Un wizard est disponible pour créer les projets destinés à être déployé sur S2AP.
Malheureusement il ne semble pas offrir d’assistance (pour le moment ?) pour la manipulation des entrées du manifest spécifiques au déploiement sur S2AP.
En particulier, même si le wizard de création d’un bundle S2AP demande le type de module (Web uniquement pour le moment) et le context path sous lequel le déployer : les entrées associées ne sont pas générées dans le manifest …

Le forum mis en place pour l’évaluation de cette version beta (http://www.springsource.com/beta/s2ap/ après enregistrement) commence à bouger.
Les développeurs de S2AP viennent d’annoncer une version de PetClinic OSGi-ifé et d’autres samples pour Mardi prochain …
Avec une vrai application, il sera plus simple de se faire une meilleur idée sur les capacités de la plateforme.

Alors et vous ? qu’en pensez-vous ?
OSGi est encore relativement confidentiel au sein de la communité. Pensez-vous que S2AP va marquer le début de l’expansion de OSGi pour les appli d’entreprises ?
L’hégémonie de JEE va-t-elle en prendre un coup ?

Qq pointeurs supplémentaires :

Le poste de Rob Harrop pour plus de détail : http://blog.springsource.com/main/2008/04/30/introducing-the-springsource-application-platform/.

Deux intros sur OSGi et Spring-DM :
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html
http://www.javaworld.com/javaworld/jw-04-2008/jw-04-osgi2.html