Le JDK propose deux utilitaires . . . → Lire la suite: Monitorer une JVM en local]]> Le JDK de Sun/Oracle propose plusieurs outils et APIs pour monitorer une jvm locale et ceci, depuis le JDK 6, sans avoir besoin de configurer cette jvm de manière particulière (enfin, ca c’est dans les cas simples nous verrons qu’il faut parfois ajouter une petit option)

Les outils du JDK

Le JDK propose deux utilitaires avec une interface graphique : JConsole et JVisualVM. Le premier permettant principalement d’accéder facilement aux MBeans JMX exposés par la JVM. Le deuxième étant beaucoup plus complet, en particulier si vous utilisez les plugins en téléchargement optionnel.

Il propose aussi des outils en ligne de commande : jps (liste des process java), jstat (statistique sur le jvm en particulier sur l’état de la mémoire), jstack (pour demander un thread dump), jmap (pour demander un heap dump),… tous présents dans le répertoire bin du JDK

Ces outils sont soumis à quelques restrictions :

• certaines sont liées à des questions de sécurité. En particulier, ils ne sont souvent utilisables que par l’utilisateur qui exécute les jvms à monitorer
• d’autres restrictions sont moins évidentes ; une partie sont décrites ici : http://visualvm.java.net/troubleshooting.html

Sous windows, je rencontre actuellement des problèmes lorsque je me connecte à un serveur à distance (via Remote Desktop) : généralement, il faut toujours au moins que je me connecte en mode admin (mstsc.exe /admin (ou /console dans les anciennes versions) ) pour que les outils de monitoring puisse fonctionner. Mais cela ne suffit pas toujours …

Accès programmatiques

Ces outils sont très intéressants, mais il est parfois nécessaire d’accéder à des métriques particulières d’une jvm ou de l’application que la jvm héberge. Ou ils peuvent tout simplement ne pas fonctionner dans certains cas particuliers.

Dans la suite de ce post, je vais me focaliser sur les différentes façons d’accéder au serveur jmx des jvms en local sans avoir à configurer l’accès distant : qui peut se révéler complexe si l’on veut que cet accès reste sécurisé ( tout est dédrit ici : http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html )

L’API Attach

L’utilisation de l’API Attach pour se connecter à un serveur jmx en local est décrit sur la même page web que l’accès distant :

http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdhkz

Cette api permet essentiellement :

• de découvrir les jvms disponibles
• récupérer quelques  informations sur ces jvms (propriétés système et propriétés des agents chargés)
• charger un agent à l’intérieur de la JVM cible

Cette dernière fonctionnalité permet en particulier de charger l’agent JMX si il n’est pas déjà lancé. On peut lancer l’agent jmx au démarrage de la jvm via l’option -Dcom.sun.management.jmxremote. A partir du JDK 6, c’est grâce à l’API Attach, que cette option n’est souvent plus nécessaire : l’agent peut être chargé à la demande comme montré dans l’exemple ci-dessous.

(ce programme nécessite que le jar tools.jar présent dans le répertoire lib du JDK soit dans le classpath)

package jmx;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.File;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.List;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;

public class JmxAttachAPI {
	public static void main(String[] args) throws Exception {
		new JmxAttachAPI().dotIt();
	}

	static final String CONNECTOR_ADDRESS = "com.sun.management.jmxremote.localConnectorAddress";

	private void dotIt() throws Exception {

		System.out.println("Available local vms : ");
		List vmdList = VirtualMachine.list();
		for(VirtualMachineDescriptor vmd : vmdList) {
			System.out.printf("%s : %s%n", vmd.id() , vmd.displayName());
		}

		// Choose one vm :
		System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        System.out.println();
        System.out.printf("Connecting to jvm : %s%n",pid);
		VirtualMachine vm = VirtualMachine.attach(pid);
		String connectorAddress = null;
		try {
			// get the connector address
			connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);

			// no connector address, so we start the JMX agent
			if (connectorAddress == null) {
			   System.out.println("Agent not Started, loading it ...");
			   String agent = vm.getSystemProperties().getProperty("java.home") +
			       File.separator + "lib" + File.separator + "management-agent.jar";
			   vm.loadAgent(agent);

			   // agent is started, get the connector address
			   connectorAddress =
			       vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);
			} else {
				System.out.println("JMX Agent already started !");
			}
		} finally {
			vm.detach();
		}

		System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

		// establish connection to connector server
		JMXServiceURL url = new JMXServiceURL(connectorAddress);
		JMXConnector connector = JMXConnectorFactory.connect(url);

		MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
               con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

	}
}

Et voici un exemple de son exécution :

Available local vms :
8372 : org.apache.catalina.startup.Bootstrap start
2108 : jmx.JmxAttachAPI

vm id ?
8372

Connecting to jvm : 8372
Agent not Started, loading it ...
Connecting to jmx server with connectorAddress : service:jmx:rmi://127.0.0.1/stub/rO0ABXNyAC5qYXZheC5tYW5hZ2VtZW50LnJlbW90ZS5ybWkuUk1JU2VydmVySW1wbF9TdHViAAAAAAAAAAICAAB4cgAaamF2YS5ybWkuc2VydmVyLlJlbW90ZVN0dWLp/tzJi+FlGgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc6AAtVbmljYXN0UmVmMgAADzE2OS4yNTQuMTQxLjIwNAAA1Qkf/eH4sQVkBOeL7SsAAAE1TnnPy4ABAHg=

Extracted classpath : C:\products\apache-tomcat-6.0.32\bin\bootstrap.jar

Après avoir listé les jvms disponibles, ce programme s’attache à la jvm sélectionné et regarde si l’agent jmx est déjà chargé (en cherchant la propriété com.sun.management.jmxremote.localConnectorAddress)

Si il ne la trouve pas, il demande à la jvm de charger cet agent (l’agent est dans le jar management-agent.jar présent dans le répertoire jre/lib/ de la jvm cible)

Notez que la JConsole fait exactement la même chose : elle l’indique d’ailleurs dans la fenêtre de connexion en affichant “Note : The management agent will be enabled on this process” sous la liste des process disponibles lorsque le process sélectionné n’a pas encore l’agent JMX chargé

Une fois l’adresse jmx locale récupérée, l’API Attach a terminé son travail. L’api JMX prend ensuite le relai.

Ici on se contente d’extraire le classpath de la JVM cible. Mais l’ensemble des MBeans JMX de la JVM sont maintenant accessibles : que ce soit les MBeans de la JVM ou les MBeans que l’application aurait exposé dans le serveur JMX de la JVM

L’API MonitoredHost

Dans certains cas, l’API Attach ne fonctionne pas … (lorsque la JVM est exécutée par un service windows en particulier ; du moins dans l’environnement où je travaille actuellement)

JConsole utilise une 2ème API pour lister les jvms et extraire des infos : sun.jvmstat.monitor.MonitoredHost. Il utilise aussi une autre api bas niveau sun.management.ConnectorAddressLink : pour récupérer l’adresse JMX local

La limitation principale de cette api est qu’elle n’est pas capable d’activer l’agent JMX s’il ne l’est pas déjà. Il faut donc l’avoir activer explicitement via l’option -Dcom.sun.management.jmxremote (même avec un jdk 6 ou plus)

Sous réserve que l’agent jmx soit activé, on peut donc accéder au serveur JMX de cette façon :

(ce programme, très fortement inspiré du code source de la JConsole, nécessite aussi que le jar tools.jar soit dans le classpath)

package jmx;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import sun.jvmstat.monitor.HostIdentifier;
import sun.jvmstat.monitor.MonitoredHost;
import sun.jvmstat.monitor.MonitoredVm;
import sun.jvmstat.monitor.MonitoredVmUtil;
import sun.jvmstat.monitor.VmIdentifier;
import sun.management.ConnectorAddressLink;

public class JmxMonitoredHost {

    public static void main(String[] args) throws Exception {
        new JmxMonitoredHost().doIt();
    }

    private void doIt() throws Exception {
        MonitoredHost localMonitoredHost = MonitoredHost.getMonitoredHost(new HostIdentifier((String)null));
        Set activeVms = localMonitoredHost.activeVms();

        Map pidToAddress = new HashMap();

        System.out.println("Available local vms : ");
        for(Integer vmId : activeVms) {
            String pid = vmId.toString();
            try {
              MonitoredVm localMonitoredVm = localMonitoredHost.getMonitoredVm(new VmIdentifier(pid));

              String commandLine = MonitoredVmUtil.commandLine(localMonitoredVm);
              boolean attachable = MonitoredVmUtil.isAttachable(localMonitoredVm);
              String connectorAddress = ConnectorAddressLink.importFrom(vmId.intValue());

              System.out.printf("%5s %30s %4s%n",pid,commandLine,attachable);
              pidToAddress.put(pid,connectorAddress);

              localMonitoredVm.detach();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

		// Choose one vm :
        System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        // get the connector address
        String connectorAddress = pidToAddress.get(pid);
		System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

        // establish connection to connector server
        JMXServiceURL url = new JMXServiceURL(connectorAddress);
        JMXConnector connector = JMXConnectorFactory.connect(url);

        MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
        		con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

    }

}

L’API LocalVirtualMachine de la JConsole

La JConsole a implémenté sa propre api de découverte au dessus des apis décrites ci-dessus : sun.tools.jconsole.LocalVirtualMachine ( On pourra trouvé son code source ici par exemple : http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/tools/jconsole/LocalVirtualMachine.java.html)

Plutôt que d’utiliser ces deux Apis directement, il est donc plus simple d’utiliser LocalVirtualMachine

Cela nous donne ceci :

( ce programme nécessite tools.jar ET jconsole.jar dans la classpath pour fonctionner ) :

package jmx;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.Map;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import sun.tools.jconsole.LocalVirtualMachine;

public class JmxJConsole {

	public static void main(String[] args) throws Exception {
		new JmxJConsole().doIt();
	}

	private void doIt() throws Exception {

		Map allVirtualMachines = LocalVirtualMachine.getAllVirtualMachines();

		System.out.println("Available local vms : ");
		for(Integer vmId : allVirtualMachines.keySet()) {
			LocalVirtualMachine vm = allVirtualMachines.get(vmId);
			System.out.printf("%10s %50s %s%n",vmId,vm.displayName(),vm.isAttachable());
		}

		// Choose one vm :
        System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        // get the connector address
        LocalVirtualMachine vm = allVirtualMachines.get(new Integer(pid));
        // load jmx agent if necessary/possible :
        vm.startManagementAgent();
        String connectorAddress = vm.connectorAddress();

        System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

        // establish connection to connector server
        JMXServiceURL url = new JMXServiceURL(connectorAddress);
        JMXConnector connector = JMXConnectorFactory.connect(url);

        MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
        		con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

	}
}

Conclusion

Avec ce dernier code, vous devriez être paré pour vous connecter en local aussi bien que JConsole et extraire vos propres métriques ou lancer des opérations de diagnostique (au hasard : lancer un heap dump) via les Apis JMX de la jvm

Toutefois même la JConsole n’arrive pas tout le temps à se connecter ou à voir une jvm local.

En cas de soucis, voici au moins trois pré-requis qui m’ont été nécessaire récemment :

• exécuter JConsole (ou votre code custom) avec le même utilisateur que la JVM cible
• si vous vous connecté en remote desktop sur un serveur Windows : utiliser le mode admin : mstsc.exe /admin
• activer explicitement l’agent jmx sur votre jvm cible (via -Dcom.sun.management.jmxremote)

L’objectif d’Hibernate OGM est d’explorer comment réutiliser Java Persistence et son API familière pour persister les entités dans une base NoSQL.

Il offre une implémentation JPA (manipulation d’objet et requêtes JP-QL) tout . . . → Lire la suite: Ippevent Hibernate OGM par Emmanuel Bernard le 9 février]]> PaaS, Cloud. Mais le vrai challenge c’est comment et où stocker vos données. Dans du NoSQL ? Peut-on utiliser une API familière ?

L’objectif d’Hibernate OGM est d’explorer comment réutiliser Java Persistence et son API familière pour persister les entités dans une base NoSQL.

Il offre une implémentation JPA (manipulation d’objet et requêtes JP-QL) tout en stockant et requêtant les données d’une grille clé/valeur (et d’autres approches NoSQL dans un second temps). Cela inclus notamment de supporter des applications JPA existantes.

Dans cette présentation, nous allons:

• faire un survol du monde (NoSQL) et voir en quoi une API comme JPA apporte un intérêt
• voir comment Hibernate OGM stocke les entités et les associations dans la base clé/valeur et explorer les compromis fait
• voir comment les requêtes JP-QL sont implémentés au dessus d’une technologie qui ne supporte pas la notion de requête (clé/valeur) et quel niveau peut être couvert

Attention: contient des démos qui tournent !

Pour vous inscrire, il vous suffit de cliquer sur le bouton ci-dessous (si vous désirez plus d’information vous pouvez aussi vous inscrire depuis notre page Ippevent :

Une critique fréquente faite à l’encontre Java EE est la difficulté à tester ses composants comme les EJB ou les Beans CDI. L’outil de test JBoss Arquillian apporte une réponse puissante à ce problème . . . → Lire la suite: Ippevent Arquillian le 19 janvier]]> Pour débuter cette nouvelle année 2012 (que je vous souhaite bonne et heureuse), nous démarrons avec un outil novateur : Arquillian.

Une critique fréquente faite à l’encontre Java EE est la difficulté à tester ses composants comme les EJB ou les Beans CDI. L’outil de test JBoss Arquillian apporte une réponse puissante à ce problème et à bien d’autres concernant les tests d’intégration.

Alexis Hassler, spécialiste Java EE 6 et membre éminent du Lyon Jug nous présentera lors de cet Ippevent cette solution de test nouvelle génération qui vous aidera que vous utilisez Java EE ou Spring.

Pour vous inscrire, il vous suffit de cliquer sur le bouton ci-dessous ou de vous rendre sur notre page Ippevent.

Il y a quelques semaines nous vous annoncions notre soutien en tant que sponsor de DevoXX France les 18, 19 et 20 avril 2012 à Paris.

Alors être sponsor c’est sympa :

http://blog.ippon.fr/2011/11/30/jeu-ippon-recrute-deuxieme-edition/

Un excellent retour sur ce jeu a été fait par Sébastien Prunier, et nous allons d’ailleurs nous baser sur sa solution pour la suite de ce billet. En effet, la dernière partie du jeu consistait . . . → Lire la suite: Attaque brute force, Java et parallélisme]]> Ippon a lancé il y a un peu plus d’une semaine un jeu qui a eu un beau succès:

http://blog.ippon.fr/2011/11/30/jeu-ippon-recrute-deuxieme-edition/

Un excellent retour sur ce jeu a été fait par Sébastien Prunier, et nous allons d’ailleurs nous baser sur sa solution pour la suite de ce billet. En effet, la dernière partie du jeu consistait à faire un algorithme de “brute force” afin de déchiffrer un mot de passe. Certaines personnes ont cru, à tort, qu’il s’agissait juste de faire une boucle “while” et de tester tous les cas possibles: cela rendait le déchiffrable impossible, à moins d’avoir beaucoup de temps disponible… Bien entendu il y avait une astuce, que pas mal de monde (dont Sébastien) a trouvé: étant donné qu’il s’agissait de trouver les lettres d’un pseudo-Sudoku, il n’y avait que 9 lettres possibles, qui ne répétaient pas, soit 9! possibilités (9! = 9*8*7*6*5*4*3*2*1 = 362 880 possibilités).

Le code de Sébastien permet ainsi de trouver la bonne combinaison en 80 secondes (sur mon MacBook):

https://github.com/sebprunier/IpponRecrute/blob/master/src/main/java/fr/ippon/rh/support/ForceBrute.java

Cependant, on peut faire plus performant: pour être exact, “probablement plus performant”, car tout dépend de vos données (plus le résultat se trouve “loin” dans notre jeu de test, plus la parallélisation va nous faire gagner du temps).

Nous allons pour cela voir plusieurs méthodes différentes: Node.js, Scala, Java “pur” et Spring.

Méthode n°1: utilisation de Node.js

Plusieurs personnes ont remonté qu’en utilisant Node.js, on pourrait certainement faire mieux. Voilà un bon exemple du “hype oriented computing”, que l’on m’a déjà sorti plusieurs fois lors du challenge USI 2011: node.js n’est volontairement pas multi-threadé, pour éviter de faire du context switching et éviter d’empiler des threads (typiquement une thread par utilisateur, comme c’est le cas dans beaucoup de nos “vieux” serveurs d’applications Java qui ne font pas de NIO). Cela permet d’avoir des applications très réactives, et qui supportent beaucoup d’utilisateurs, à partir du moment où ces applications “attendent” la majeure partie du temps. C’est un cas classique d’utilisation des serveurs d’applications: ils passent une grande partie de leur temps à attendre les données provenant d’une base de données. Node.js est donc particulièrement adapté à des sites Web utilisant une base de données complexe, mais est par contre peu adapté à des sites Web faisant beaucoup de calcul en local: un excellent exemple est donné en début du post maintenant célèbre “Node.js is Cancer“.

Ajoutons que sur nos machines modernes, l’histoire va plutôt dans le sens inverse de Node.js: nous avons de plus en plus de coeurs, chacun étant généralement moins puissant que la génération précédente.

Méthode n°2: utilisation de Scala

Scala 2.9 permet d’avoir des collections utilisant automatiquement les différents coeurs de votre système: c’est en quelque sorte l’inverse de l’approche de Node.js! Vous pouvez donc itérer sur une collection, et les traitements sur cette collection utilisent alors automatiquement plusieurs threads, répartissant ainsi les traitements sur l’ensemble des coeurs du système.

(1 to 1000000).toArray.par.map(_*2)

Le .par dans le code précédent dit à Scala d’utiliser les collections “parallèles”. Dans la pratique, ce code a cependant beaucoup de problèmes:

• Il va utiliser le framework Fork/Join de Java 7: donc si vous êtes sour Mac OS X, comme moi, cela ne va simplement fonctionner que sur une seule thread.
• <troll> Il est écrit en Scala, et donc personne ne le comprend </troll>

Méthode n°3: Java pur

package fr.ippon.rh.service;

import org.jasypt.util.text.BasicTextEncryptor;

import java.util.*;

/**
 * Resolution de l'etape 3 par force brute.
 *
 * @author Sébastien Prunier
 * @author Julien Dubois
 */
public class MultiForceBrute {

    // Texte a decrypter
    private static final String etape4Texte = "5oi/MCVWOrk2V8bI2LY4XM4gKf/hqRnz6/d0HftJYadMv7xkIjUsTfvXyyf0kJ/D1Or0QMicOUf7YIAkAMWkbNJpLA5cgOHZvGZVC1LBGdpe0n3zY5VfyYjUIFu/0VNyLVMOAu4BaC3ncdPkh5Q0r+IQeTV+IqOOBlsozTfxeLYBJhxIUdSaXIVubo7RSPOn1Y0aLrTEZhlPkJFJhQohhOr5d0/zqre7HnFdc/9vSC3qda6VKwxd+yAhl762kOGReE4YbeMX/1wg175ruUaT4tgVYaOLXIRg0fqZYIwu37KUrOvtUD+inZSYwMpUrNSeV9Wshwoi6kBXkriEoc2Qg58b6WVfNTzGMFsRp/D4TGMx04hGg2WTT4lRPebqGl5cPm6qSeb7WET3xbJ4LUCvOgX0cDr22inxlGUgkbF7m8ApZw2kOverBgnhW+dE3amE+bP1Ac1ky4sSY0Sjeec2n4QI6hX9mwl7GBc9Ep8uF7t+XdZFmuml4/bFgxtDOpi8zQ6NYXe2/UT5S6i/hPPHHRa6OGL2ZAswBtAkcsYiw564hshKvzVOMtP05Zu19C1zY+84kmpsGbxxknSI61owCNOvF1tJitww4EmkLsIhgveV+RcmTQOiwONJET7Q9qK4RFpFuz+hu1Kel0QsMPZMlvhSsSTj+lmLHzG9nC5s4RcvLR1JeL27MvcfO0CxZx9XSYazu+LqVK2qlv+NXftT9JFx19hVIvAI/T4oM9xf3wYrLozs1GDRrPju2yVXZb91vn4TdWWIoXI8yGQ5AaHYVLNu5LVez/Q4sH/DRjjMHLGTsYpXNm/xRrwf10Aw78dO58dvUy+ClP6//0wq+9+tw4knCtZwPK6Ov1gqvCzUlp3voDO+J/7/9+OoA4OkdJv8Nsu02lWZ6/mDsrr49U8D8mJgmqze4jVLbXg61HCuzSCOhnHPtMmyfykDSFHXvSGCiuyGoWN5ObIAo/k9XxYlZNrGpwYq3aTwaKJwG1vTtLzHop0bfQ50+cz18LqynMB2t+Y5AQ9IGAvJX6nWrO/C8GBD/bE/lZT+i1XYhYJ0JB0zoadQK+AkyNNiwUe9Dv31e614zgVTGlJ/JvSQGBCAcK+wYNDK1fVY2EEWyQhlQ3BYdwcqF4myOI7wtZsPscwO1Kc8TwlPGypQ/6JG4Q5AUeXmzrXi67boN0tB4YUyG5cQk7Ehe3gaHI7rF5IGYT1id7agEcxphjRWMTo9fT9zIb2tsA9SBw+tici5y2E7xHbnEcMjF4xuGWjEy7sr8+PktLQldvcyAo0jkwlN8G6PyL7R1HcWITr8W9T3Qr4Yq3vazV16pDf7tofDEdoI9/9jt8wchTd1gCh/fnZk88TblEJqGnbrsPL+V2S+/YaLv7A7nZ1Bjy9WiQYiGnO1tgqMMbwt470eb1mIKyOcarrGcAATiEq8DxE1H8xeEpy23BtdTHJwT5COhCY+WbEWcYvCh6tBVs2PPvGSCJvClW2sR0n16kdtQiYS7uOiyOANoVy5ZygJ4jITiik3Lcfm3rE1DLaOM44DjRy1W5YTq7dXYKBsXcdoc+JmZ+7naVcBQ2q2XlZ/t2EvN9k1rVW4x7o7V7YsE2bbPqyvAxt0w1NsgVUaAsff361KxJgD7JXQXdpEyD+6KE1N+SmUOOUG22OxOZbsHy/+WPTKboQ5AMFG8pgR61TfAA6YqPakrGMKYGkpe0T+1t82Zo1t3Q+z2WxSLdRX5bslJjfuZSqqCpao40BbIEEFYAlmkTgDuKIaP4dA9o+b0M+lPjIM/mwWjxDdOraR3w0ncnyrUigGGisYsT5KHh89VHcyv94gJdMeT+5LC/7plTAd5HhMfp1Gq8f/6L1NWuhgyD/ne8VhNOuThkf53e5QzEuhUJqc8P/A68U/TG83SFgVRiPG2h06bEGC6yztEYlT/LPBQJkcB0I2Yg4BbcJRXTc6mZT54Fato3zRPYlqXdniQsxTR8w6WgVbRF93bn99lrJc9lLnqn9F8cFTG5QKp9u45yExo2Hy/0jmcpHyhaLlJP/ECuEeQK7M5H2Ro3rG2wwcAiuK0JV0meM6Isij2z4ldl2agyR2TKNgVcCynrScqFpzkEgwmPY6XuU/+qN89fgsRJ+8uuL0V1ah4zl70ymEzMYX48bI8icCIP4BFVp+mBymy2AUo7ln8zfxW4DKlZgVeyBsluDUqjn111m4oq/JkbzwlW3/D+KU9Yb52KwcHmbnpO8TcKXprhk2iJ04ak3IWY1u+pNU8WZRz3+jQWoPpIQtA8DQQdIYXrKwgXVerMsp2g4Tj0Irf5RnpcbjzXNM2A2mBo6ak/dp1I0tFK3Ue5HfSeBZ6iLBGsKii8VJPCw2AxM/JI74/Cl2BaggiMvpqAhMDyG7EhnaMZfgj+8Kd9P1hTp5nsZWGe3vnwDLLpnDqH4vER7J1uKpm3ig2XGuq3XFo7Fp6naG+B7qlSRF";

    private static long startTime;
    private static boolean stopDecryption;

    /**
     * Programme principal
     */
    public static void main(String args[]) {
        startTime = Calendar.getInstance().getTimeInMillis();

        MultiForceBrute multiForceBrute = new MultiForceBrute();
        multiForceBrute.decrypt();
    }

    private void decrypt() {
        Set passwords = new HashSet();
        permute("", "ABCDEGHIJ", passwords);
        System.out.println("Password size: " + passwords.size());

        int cores = Runtime.getRuntime().availableProcessors();
        System.out.println("Number of cores: " + cores);
        String[] passwordArray = new String[passwords.size()];
        passwordArray = passwords.toArray(passwordArray);
        Collection partitions = new ArrayList();
        int partitionSize = passwordArray.length / cores;
        for (int c = 0; c < cores; c++) {
            String[] partition = Arrays.copyOfRange(passwordArray, c * partitionSize, (c + 1) * partitionSize);
            partitions.add(partition);
        }
        for (String[] partition : partitions) {
            DecryptionThread decryptionThread = new DecryptionThread(partition);
            decryptionThread.start();
        }
    }

    /**
     * Calcul des permutations.
     *
     * @param sStart    chaine de depart.
     * @param sEnd      chaine d'arrivee.
     * @param passwords ensemble des mots de passe.
     */
    private void permute(String sStart, String sEnd, Set passwords) {
        if (sEnd.length()             passwords.add(sStart + sEnd);
        } else {
            for (int i = 0; i < sEnd.length(); i++) {
                String newString = sEnd.substring(0, i) + sEnd.substring(i + 1);
                permute(sStart + sEnd.charAt(i), newString, passwords);
            }
        }
    }

    private class DecryptionThread extends Thread {

        private String[] passwords;

        DecryptionThread(String[] passwords) {
            this.passwords = passwords;
        }

        public void run() {
            for (String password : passwords) {
                if (stopDecryption) {
                    return;
                }
                try {
                    BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
                    textEncryptor.setPassword(password);
                    String decryptedText = textEncryptor.decrypt(etape4Texte);
                    if (decryptedText.contains("ippon")) {
                        System.out.println("Result: " +password);
                        long totalTime = Calendar.getInstance().getTimeInMillis() - startTime;
                        System.out.println("Solved in: " + totalTime + " ms.");
                        stopDecryption = true;
                    }
                } catch (Exception e) {
                    // Bad password !
                }
            }
        }
    }
}

Méthode n°4: Spring

Les trois solutions que nous avons vu, malheureusement, ne sont pas très industrielles: sur un projet en production, personne n’a envie de lancer ainsi des threads qui utilisent tous les coeurs disponibles, sans aucun contrôle.

Pour cela Spring propose une abstraction très intéressante, le TaskExecutor. Nous utilisons ici Spring 3.0 (voici la documentation officielle), sachant qu’il est prévu que Spring 3.1 supporte le framework Fork/Join, comme Scala, mais qu’à l’heure actuelle (Spring 3.1.0.M1), la documentation n’est pas à jour.

Dans sa version la plus simple, ce TaskExecutor permet de définir un pool de threads:

<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
  <property name="corePoolSize" value="5" />
  <property name="maxPoolSize" value="10" />
  <property name="queueCapacity" value="25" />
</bean>

Dans la pratique, ce système permet de centraliser dans un seul endroit la configuration de son pool de Thread, et de pouvoir ainsi l’optimiser:

• On peut bien entendu utiliser le nombre de coeurs disponibles: c’est une variable qui est tout à fait intéressante, car dans un environnement virtualisé le nombre de coeurs disponibles peut être amené à évoluer
• On peut utiliser la configuration Spring pour modifier ces valeurs en fonction des environnements: c’est la notion de profils, qui va elle aussi apparaître avec Spring 3.1, mais qui elle est très bien documentée
• On peut choisir de n’utiliser qu’un seul thread: c’est ce qui arrive en fait très souvent pour les applications Web, car on veut garder la majeure partie des coeurs disponibles pour les utilisateurs. Ainsi, l’ensemble des traitements de fond sont soumis à une seule et même thread, ce qui permet d’avoir une application toujours réactive, quels que soient les traitements lancés. L’intérêt ici est également d’utiliser la même thread pour des traitements différents.
• On peut utiliser le pool de thread du serveur d’applications, et c’est ce que nous allons détailler plus bas.

<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
    <property name="workManagerName" value="wm/default"/>
    <property name="resourceRef" value="false"/>
</bean>

Cette configuration permet ainsi au administrateurs de votre serveurs d’applications de modifier le nombre de threads disponibles en fonction des besoins et des capacités disponibles, ce qui est essentiel en cas de charge importante sur le serveur.

https://github.com/ippontech/IpponRecrute

Cependant, certaines personnes ont trouvé ce jeu trop facile, et nous avions alors promis une nouvelle version plus difficile… Voici donc la deuxième édition de ce jeu!

La session du Paris JUG du 8 novembre 2011 était consacrés aux petites librairies Java.

Guillaume Laforge, leader du projet Groovy nous a présenté la librairie PrettyTime développée par Lincoln Baxter III qui travaille chez OcpSoft et RedHat. Celle-ci permet de présenter des dates sous forme . . . → Lire la suite: Paris JUG : Petites librairies Java]]>

G. Laforge expliquant Pretty Time

La session du Paris JUG du 8 novembre 2011 était consacrés aux petites librairies Java.

I. Pretty Time

Guillaume Laforge, leader du projet Groovy nous a présenté la librairie PrettyTime développée par Lincoln Baxter III qui travaille chez OcpSoft et RedHat. Celle-ci permet de présenter des dates sous forme de dates relatives du type : à l’instant, dans 10 minutes, il y a 3 heures. Guillaume l’utilise sur son blog pour afficher la date des posts ce qui permet d’indiquer la date de la façon suivante : Posted on 09 November, 2011 (2 days ago). La librairie est constituée d’un jar n’a pas de dépendance. Elle supporte 18 langues dont le français et l’anglais et est très simple à utiliser.

// on initialise avec une date de reference
PrettyTime t = new PrettyTime(new Date(1000 * 60 * 12), new Locale("fr"));
// on formate une date par rapport a cette date de reference
assertEquals("il y a 12 minutes", t.format(new Date(0)));

on peut utiliser facilement PrettyTime avec Grails ou JSF.

II. GPars

GPars (prononcez Jeepers) est une librairie permettant de s’adapter au multi-processeurs et au multi-coeurs en faisant de la programmation concurrente.

il est difficile de bien utiliser ce  que le JDK propose : threads / synchronize / wait-notify-notifyAll, qui peuvent conduire à

• des dead-locks, des live-locks (in interblocage qui consomme du CPU), des race conditions ou l’épuisement de ressources
• des problèmes de gestion d’accès à la mémoire partagée

Pour éviter ces problèmes, GPars propose d’utiliser l’immuabilité et le passage de messages au travers des paradigmes suivants

• Acteurs
• Fork/Join
• Collections parallèles
• Executors
• Dataflow
• Agent – an thread-safe reference to mutable state
• STM (Software Transactional Memory)
• CSP

un exemple avec les fonctions parallèles pour les collections

@Grab('org.codehaus.gpars:gpars:0.12')
import static groovyx.gpars.GParsPool.withPool

defnums=1..100000
withPool(5){
def squares=nums.collectParallel{it**2}
.grepParallel{it%7==it%5}
.grepParallel{it%3==0}
println squares[0..3]+"..."+squares[-3..-1]

assertsquares[0..3]==[36,144,1089,1296]
}

on utilise un pool de taille nombre de coeurs + 1 afin de maximiser l’utilisation du CPU car souvent on a un thread qui sert à la coordination des autres et qui consomme peu de ressources. GPars a comme dépendance les librairies jsr166y et extra166y. Il dispose d’une API Java et d’une API Groovy.

Selon le problème que l’on a à résoudre on utilisera des outils différents. Cela est bien présenté par le graphe suivant.

les slides de la présentation de Guillaume ici

III. Project Lombok (ou comment cacher la plomberie)

Florent Ramière de la société Jaxio nous a présenté Lombok, “un outil qui sert à enlever la plomberie”. Il s’agit d’un plugin eclipse qui va générer du code technique grâce à des annotations, le source ne sera donc pas pollué par ce code technique qui existera néanmoins dans le bytecode après compilation. En utilisant Lombok on pourra donc clarifier son code et se concentrer sur d’autres parties de son code. On peut bien sûr utiliser les assistants eclipse pour générer un code similaireà celui généré par Lombok.

on dispose notamment des annotations suivantes

@Getter

@Setter

@EqualsAndHashCode

@RequiredArgsConstructor un constructeur avec tous les champs finaux

@Data est un raccourci pour @ToString, @EqualsAndHashCode, @Getter sur tous les champs et @Setter sur tous les champs non-finaux, et @RequiredArgsConstructor! à utiliser pour ses beans.

@Delegate permet de déléguer toutes les méthodes publiques de l’attribut annoté, excepté les méthodes présentes dans java.lang.Object.

@Log et ses variantes @CommonsLog, @Log4j et @Slf4j permet d’instancier une variable statique privée log

@Synchronized permet de générer un bloc synchronize sur une variable privée $lock ou $LOCK (dans le cas d’une méthode statique)

val est un type Lombok permettant d’avoir des variables ‘final’ et de bénéficier de l’inférence de type.On peut ainsi écrire

val map = new HashMap();

la page suivante explique très bien le code généré par Lombok. on peut d’ailleurs si besoin générer ce code en utilisant delombok (pour GWT notamment ou si l’on veut utiliser le code générer sans dépendre de lombok). lombok-pg est un ensemble d’extensions pour lombok.

Lombok peut également être utilisé via ant, maven ou javac.

Au détour de ses démonstrations, florent nous a également conseillé l’outil awaitility qui permet de faire des tests sur du code asynchrone

IV. Apache Commons Configuration

Emmanuel Bourg est membre de la fondation Apache et est commiter sur le projet Apache Commons Configuratio qu’il est venu nous présenter. Il s’agit d’une abstraction de la configuration d’une application qui présente une interface simple de type clé/valeur pour les données. Elle permet de gérer différents formats de données et des transformations dans les types voulus.

On peut gérer un format Properties amélioré

list1=val1,val2,val3
list2=val1
list2=val2
list2=val3
include=chunk.properties

On peut également utiliser des fichiers XML, Property List XML, Ini ou encore une base données.

Plusieurs formats sont prévus : OGDL, YAML, JSON, Registry Windows, Binary Property List. Les contributions sont les bienvenues si vous voulez aider à ajouter le support des nouveaux formats. On peut combiner plusieurs configurations grâce à CompositeConfiguration. On peut également utiliser un descripteur de configuration. Commons Configuration s’intègre très bien avec la librairie d’abstraction de systeme de fichiers Apache Commons VFS.

Sauvegarde automatique

PropertiesConfiguration config = new PropertiesConfiguration("usergui.properties");
config.setAutoSave(true);

Rechargement automatique (on peut également déclencher le rechargement)

PropertiesConfiguration config = new PropertiesConfiguration("usergui.properties");
config.setReloadingStrategy(new FileChangedReloadingStrategy());

V. Guava (N’aime pas les null)

Thierry Leriche-Dessirier (Indépendant) et Etienne Neveu (SFEIR) nous ont fait faire un tour du propriétaire de Guava, la librairie utilitaire de Google autrefois nommée google-collections.

Factory methods

Inférence de type : grâce à des factory statiques on peut écrire

List primeNumbers = newArrayList();
Set colors = newTreeSet();
Map ages = newHashMap();

ce qui n’est plus si intéressant que ca en Java 7 avec la notation diamant.
L’initialisation de collection est également facilitée

List dogs = newArrayList(Dog1, Dog2, Dog3)

Programmation fonctionnelle

On peut filtrer une collection grâce à un prédicat

Iterable maleDogs = Iterables.filter(dogs,
  new Predicate() {
    public boolean apply(Dog dog) {
      return dog.getSex() == MALE;
    }
});

un predicat peut utiliser les prédicats and, in, or, not déjà définis dans la classe Predicates

boolean isMilouInBoth = and(in(dogs), in(superDogs))
            .apply(new Dog("Milou"));

on peut transformer les elements d’une liste en utilisant une Function

List chiens =
Lists.transform(dogs, new Function() {
  public Chien apply(Dog dog) {
    return new Chien(dog.getName());
  }
});

Attention ce sont des vues qui sont retournées. cela peremt d’avoir du lazy-loading mais la conversion sera faite autant de fois que nécessaire.
Iterables.find utilise le même prédicat que pour Iterables filter mais renvoit le premier objet correspondant au predicat ou un objet par défaut si rien ne correspondait au prédicat.

Dog firstMale = Iterables.find(dogs, malePredicate, DEFAULT);

collections immuables

on a des syntaxes plus concises que la syntaxe standard tout en proposant de la copie défensive.

ImmutableSet.of(1, 2, 3, 5, 7);
ImmutableSet.copyOf(favoriteColors)

base.Objects

cette classe propose d’aider à la simplification de l’écriture des méthodes equals(), hashcode() ou toString()

//equals
Objects.equal(name, that.name)
&& Objects.equal(weight, that.weight)
&& sex == that.sex;
// hashcode
Objects.hashCode(name, weight, sex);
//toString
Objects.toStringHelper(this)
   .add("name", name)
   .add("weight", weight)
   .add("sex", sex)
   .toString();

on peut créer facilement un comparateur

public int compareTo(Dog other) {
  return ComparisonChain.start()
    .compare(name, other.name)
    .compare(weight, other.weight)
    .compare(sex, other.sex)
    .result();
}

base.Preconditions

on peut vérifier des paramètres

this.currency = checkNotNull(currency, "currency cannot be null");
checkArgument(amount.signum() >= 0, "must be positive: %s", amount);

base.CharMatcher

il s’agit d’un outil permettant d’exprimer une expression régulière en language naturel. Il permet de remplacer avantageusement StringUtils des Apache Commons.

Collections

on dispose de collections n’existant pas dans le JDK

MultiMap : il s’agit d’une map pouvant avoir plusieurs valeurs pour une même clé

Multimap favoriteColors = HashMultimap.create();

BiMap : il s’agit d’une map pouvant n’ayant pas 2 fois la même valeur

BiMap favoriteColors = HashBiMap.create();

Multiset: il s’agit d’un set pouvant contenir plusieurs fois la même valeur (on peut même connaître le nombre de doublons)

Multiset primeNumbers = HashMultiset.create();

Joiner et Splitter permettent de manipuler les conversions entre chaine de caractères et liste de String.
En utilisant Joiner, on aura une NullPointerException si un des éléments de la liste vaut null mais l’on pourra utiliser skipNulls() ou userForNull(MY_DEFAULT) pour spécifier le comportement lorsque l’on rencontre un null.

List<String> dogs = newArrayList("Milou", "Idefix", "Rintintin");
String names = Joiner.on(", ").join(dogs);

En utilisant Splitter on peut nettoyer le résultat en utilisant trimResults() et omitEmptyStrings()

Iterable<String> superDogs = Splitter.on(",")
   .trimResults()
   .omitEmptyStrings()
   .split("Lassie, , Volt, Milou");

Cache

Memoization

la memoization permet de garder en cache une unique valeur. l’exemple donné était la mise en cache du numéro de version du dernier jdk. On défini via l’utilisation d’un Supplier comment aller chercher la valeur qui nous intéresse. Celle valeur ne sera récupérée que lors du premier appel (lazy loading). Les appels suivant utiliserons le cache.

private Supplier<JdkVersion> versionCache =
  Suppliers.memoize(
    new Supplier<JdkVersion>() {
      public JdkVersion get() {
        return jdkWebService.checkLatestVersion();
      }
    }
);

On peut également préciser une durée de validité du cache avec memoizeWithExpiration()

Key-Value

On peut construire un Cache à plusieurs entrées grâce aux classes CacheBuilder et CacheLoader

private Cache<Long, Film> filmCache = CacheBuilder.newBuilder()
  .maximumSize(2000)
  .expireAfterWrite(30, TimeUnit.MINUTES)
  .build(new CacheLoader<Long, Film>() {
    public Film load(Long filmId) {
      return imdbWebService.loadFilmInfos(filmId);
    }
});

Concurrent

Guava propose d’étendre Future avec la classe ListenableFuture. On peut ainsi associer un listener à un Future.

ListenableFuture<Result> future = ...
future.addListener(new Runnable() {
  public void run() {
    logger.debug("Future is done");
  }
}, executor);

On peut également faire de la programmation asynchrone grâce à FutureCallback. cela permet d’isoler le traitement des exceptions.

Futures.addCallback(future, new FutureCallback<Result>() {
  public void onSuccess(Result result) {
    storeInCache(result);
  }
  public void onFailure(Throwable t) {
    reportError(t);
  }
});

pour utiliser des ListenableFuture on utilise un ListeningExecutorService de la façon suivante.

ListeningExecutorService executor = MoreExecutors.listeningDecorator(executor);

public ListenableFuture<Note> getNote(final Film film) {
  return executor.submit(new Callable<Note>() {
    public Note call() {
      return imdbWebService.getNote(film);
    }
  });
}

En utilisant les méthodes proposées par Futures on peut facilement proposer des méthodes non bloquantes qui renvoient un Future au lieu d’une liste de notes. Cela permet au programme appelant de ne pas bloquer pendant la récupération des notes et d’effectuer d’autres traitements pendant celle-ci.

ListenableFuture
<List<Note>> getNotes(Film film) {
  ListenableFuture<Note> noteImdb = imdbService.getNote(film);
  ListenableFuture<Note> noteAllo = allocineService.getNote(film);
  return Futures.allAsList(noteImdb, noteAllo);
}

Personnellement, ce sont ces deux nouveaux langages qui . . . → Lire la suite: Devoxx: Les deux nouveaux candidats à la succession au langage Java]]> Deux nouveaux langages qui commencent fort

Lors de ce Devoxx 2011, une catégorie de sessions était consacrée aux différents langages de la JVM.
Etaient présents Scala, Phantom, Groovy, JRuby, Clojure et les deux petits nouveaux révélés cette année par leur sponsor : Kotlin (JetBrains) et Ceylon (JBoss/Redhat)

Personnellement, ce sont ces deux nouveaux langages qui m’intéressaient le plus : j’adore la concision de Groovy mais le fait qu’il ne soit pas statiquement typée m’empêche de l’utiliser pour un projet avec un minimum d’envergure. Peut-être que l’un de ces deux langages pourra amener le meilleur de ces deux mondes…

Ces deux langages sont tout nouveaux et toujours en cours d’implémentation. Il n’est pas encore question de les utiliser sur de vrais projets mais nous avons pu voir durant les sessions de Devoxx que chacun avait déjà un compilateur fonctionnel et un IDE pouvant faire la démonstration de complétion, refactoring, debugging, … De quoi commencer à jouer avec a priori.

Caractéristiques

Ces deux langages ont une bonne partie de leurs objectifs en commun :

• langage s’exécutant sur la JVM
• statiquement typé
• compilateur permettant de détecter plus d’erreurs
• avoir une syntaxe plus simple et plus expressive que Java sans être aussi compliqué que Scala
• complètement interopérable avec Java

Il en ressort un grand nombre de caractéristiques communes, comme par exemple :

• inférence de type étendue
• null safety (cf ci-dessous)
• smart cast ou plus généralement des optimisations de syntaxe locale (cf ci-dessous)
• constructeur primaire dans la syntaxe

Par contre, durant la présentation de Ceylon la notion de closure n’a pas du tout été évoquée, il n’est pas clair pour moi si elle sera supporté ou non. Kotlin de son côté les supportera très bien, avec en particulier la possibilité de mettre en oeuvre des “higher-order function”.

Je ne peux pas faire de comparaisons précises sur la base de ces deux présentations, mais au dire de Stéphane Epardaud qui nous a présenté Ceylon avec Emmanuel Bernard : Ceylon et Kotlin ont beaucoup en commun en termes de fonctionnalités. Pour lui, Ceylon se distingue par un système de typage plus abouti ( avec en particulier les union type, intersection type, … ).

Syntaxe

Au niveau de la syntaxe, les deux langages restent assez accessibles aux programmeurs Java, mais s’éloignent tout de même de la syntaxe Java.
Pour citer deux exemples :

• dans Kotlin : le type des paramètres est écrit après son nom, et le type de retour après la définition d’une fonction. Par exemple :

fun main(args : List<String>) : Unit

• dans Ceylon : de nouveaux keywords sont introduits qui remplacent une partie de ceux utilisés en Java ( abstract => formal, @Overide => actual, public/protected remplacé par “shared”, …), du code peut être associé à des properties (pour implémenter le getter ou le setter associé), …

Documentation

Jetbrains a très rapidement mis en place un wiki pour son langage avec pas mal de documentation et des discussions sur les choix effectués et leurs objectifs : http://confluence.jetbrains.net/display/Kotlin/Welcome

Pour Ceylon, c’était plutôt le brouillard en terme de doc, la plupart des références se trouvaient dans des blogs, des présentations, … rendant difficile la création d’un communauté.

Jusqu’à ce matin en fait, où ils nous ont révélé une “One more thing” à la fin de la présention : le tout nouveau site de ceylon : http://www.ceylon-lang.org/ et le github des développements en cours https://github.com/ceylon

Un petit focus sur deux des caractéristiques communes

Null safety

Dans les deux langages : les références ne peuvent pas être null par défaut.
Un type Integer (par exemple) correspondrait à un objet entier non null.
Un type Integer? correspondrait à un objet entier pouvant être null

Pour accéder à un champ ou une méthode sur une référence pouvant être null, il faut absolument utiliser ?. au lieu de simplement . sans quoi le compilateur génère une erreur. Si l’objet est null : l’opérateur ?. aura pour effet d’ignorer la suite de l’expression et de renvoyer simplement null
Exemple en Kotlin :

Int? x = getAnIntegerOrNull()
print (x?.times(2)) // ici, x peut être null : il est nécessaire d'utiliser ?.
                    // pour appeler la méthode times qui correspond à l'opérateur *
if(x!=null) {
  print(x * 2)    // ici, le compilateur sait que x n'est pas null,
                  // on peut utiliser x * 2 qui est équivalent à x.times(2)
)

Exemple en Ceylon :

Cube? cube = getCubeOrNull()
print cubs?.area()
if(exists cube) {      // permet de tester que la référence n'est pas null
  print cube.area()
} else {
  print "Cube is null"
}

Smart Cast

En Kotlin :

Object object = ...
if(object is String) {
  object.substring(1)  // pas besoin de caster l'objet en String,
                       // le compilateur le déduit de la clause if
}

En Ceylon :

Apple|Snail food = ...  // union type : food référence un objet soit de type Apple soit de type Snail.
if(is Apple food) {    // on s'assure que food est de type Apple
  food.eat()    // la méthode eat() n'existe que sur Apple, et pas sur Snail
                // dans le bloc du if, il n'est pas nécessaire de caster food en Apple pour l'appeler
}

On peut aussi considérer les deux exemples du paragraphe “null safety” comme des smarts cast : où le compilateur change le type de la référence d’un type nullable à un type non nullable.

Conclusion

Plus simple que Scala, ces langages pourraient répondre aux attentes de ceux qui veulent un langage sur la JVM qui soit plus expressif que Java.

Mais attention, Groovy les attend au tournant : la vérification statique du typage est en cours d’implémentation pour la prochaine version du langage : http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking

Il permettrait d’indiquer au compilateur d’effectuer un contrôle de type strict sur certaines classes : tout compte fait c’est peut-être juste ça que j’attendais moi !

Pour ceux qui ne connaissent pas Play! (et qui visiblemement ne lisent pas ni le blog d’Ippon, . . . → Lire la suite: Devoxx: Play! Framework 2.0]]> Deuxième retour de la conférence Devoxx qui bat en ce moment même son plein à Anvers en Belgique. J’ai assisté hier matin à la session sur Play! Framework 2.0 animée par Guillaume Bort et Sadek Drobi.

Introduction

Pour ceux qui ne connaissent pas Play! (et qui visiblemement ne lisent pas ni le blog d’Ippon, ni le Touilleur Express), il s’agit d’un framework orienté web, full-stack (contient toutes les briques nécessaires pour développer, déjà intégrées et configurées), et qui met l’accent sur la facilité et la rapidité de développement. Il a aussi la particularité de ne rien faire comme les autres… Pour résumer grossièrement, il s’agit d’un équivalent de Ruby on Rails pour le monde Java.

Guillaume Bort, créateur du framework, et Sadek Drobi, un des développeurs principaux, nous ont donc parlé de la prochaine évolution majeure du framework. Ils commencent par faire deux annonces:

• La sortie de la première bétâ de la future version 2.0.
• Typesafe (la société créée par Martin Odersky et Jonas Bonér, les créateurs de Scala et d’Akka respectivement), vont intégrer officiellement Play! 2.0 dans leur stack. Une intégration naturelle puisque Play 2.0! s’appuie fortement sur Scala, Akka et sbt… Guillaume Bort en profite également pour intégrer l’Advisory Board de Typesafe, où il sera plutôt en bonne compagnie puisqu’il y rejoint James Gosling et Doug Lea.

Historique

Sadek Drobi, commence par nous rappeler que le framework Play! est né chez Zenexity pour répondre aux besoins de projets réels, avant d’être rendu open source. Il nous fait un rapide rappel de l’évolution du web ces dernières années: d’abord un web statique, composé de simples pages HTML, puis un web dynamique, où on découvre que l’on peut manipuler une page dynamiquement, parfois avec certains excès, ce qui donne lieu à une phase de structuration qui est celle dans laquelle nous nous trouvons actuellement.

Selon Sadek Drobi, la prochaine étape qui nous attends est celle du temps réel, où les informations dans la page seront mises à jour en permanence (pensez Twitter…). Cette évolution du web entraine de nouvelles contraintes : besoin d’une gestion efficace des flux de données, une gestion plus facile de la concurrence, une meilleure élasticité au déploiement… Le but de Play! 2.0 est de répondre à ces nouveaux besoins tout en gardant la philosophie qui le caractérise: prise en main facile et intuitive, full-stack, rapidité de développement…

Nouveautés

Guillaume nous fait ensuite une démo rapide de la console Play! Il s’agit en fait de la console SBT. On peut y lancer des commandes comme compile ou run. SBT est wrappée dans le script “play” ce qui permet d’utiliser les même commandes que pour Play! 1.x (ex: play new, play run, play test…). On peut également lancer l’interpréteur scala depuis la console, et ainsi avoir accès directement aux classes de notre projet, y compris les templates compilées. On peut donc appeler une template à la main et voir tout de suite le HTML généré. Utile pour débogger…

Guillaume nous montre ensuite qu’on peut mélanger Java et Scala dans le même projet, avec le même système de recompilation à la volée, de rechargement à chaud, et d’affichage des erreurs directement dans le navigateur. Il nous présente aussi le nouveau système de templating. Exit Groovy, place à Scala.  L’avantage est que les templates sont compilées comme des fonctions Scala, et bénéficient de tous les avantages du typage fort. Si vous renommez un champ d’un bean, vous saurez dès la compilation que vous avez oublié de mettre à jour un template. Plutôt pratique…

Fin de la démo. Sadek reprend la parole pour nous parler des besoins grandissant d’asynchronicité pour les applications web. Lorsqu’on appelle un système externe pour récupérer des données (appel REST, WS, ou autre…), il n’est plus question de bloquer un thread de traitement des requêtes pendant qu’on attend la réponse. Lorsqu’on veut traiter un gros flux de données, il n’est pas question de tout charger en mémoire pour le traiter ensuite. Il faut mieux maîtriser la consommation des ressources (threads, CPU, mémoire). Il faut sortir des API bloquantes (genre InputStream), et mettre en place une méthode plus efficace que simplement passer un callback à une méthode asynchrone. Sadek nous dit qu’il faut faire du “reactive programming”: réagir à des évènements (une requête arrive, la réponse d’un processus long est arrivée…).

Il introduit ensuite la réponse de Play! à ce problème: le concept d’Iteratee et d’Enumerator. Concept apparement inspiré par le langage Haskell. De ce que j’en ai compris, il s’agit d’une sorte d’un producteur (l’Enumerator) qui notifie un consomateur (l’Iteratee) que de nouvelles données sont disponibles. L’Iteratee peut ensuite répondre de plusieurs façons:

• Continue: envoie moi encore des données, et traite les de cette façon là.
• Stop: arrête de m’envoyer des données (et libère potentiellement les resources)
• Error: tu m’envoies des données invalides.

Play! utilise Akka et le modèle d’acteur pour implémenter ces concepts. Ce point à vraiment l’air d’être une des nouveautés importantes, et je suis curieux de voir un exemple concret de mise en pratique de ce pattern…

Sadek nous parle ensuite de la couche de persistance. Il nous dit qu’il est illusoire pour eux d’essayer de faire une couche d’abstraction générique de la persistance, les technologies sous-jacentes étant trop différentes (bases relationnelles, bases NoSQL, etc…). Ils préfèrent implémenter des API spécifiques grâce à des modules spécifiques. Pour la version Scala, l’implémentation par défaut est Anorm (une simple couche au dessus de JDBC). Pour la version Java, EBeans est utilisé comme implémentation légère de JPA.

Sadek et Guillaume nous parlent ensuite de l’avantage d’utiliser SBT comme outil de build. SBT étant extensible, il est possible d’écrire des modules qui viendront étendre le cycle de vie de l’application. Par exemple, on peut déclarer des “compiled assets”, c’est à dire des resources qui seront compilées automatiquement par Play! en cas de changement, et dont les erreurs seront affichées dans le navigateur, de la même manière que pour les fichiers sources Java ou Scala. On peut par exemple gérer ainsi la compilation des CSS avec Less, ou bien des fichiers Javascript avec CoffeeScript.

Conclusion

En conclusion, la réécriture de Play! leur a apporté un certain nombre d’effets de bords bénéfiques, tels que de meilleures performances, mais aussi d’apporter du “type-safety” partout, y compris dans la couche présentation (les templates), et dans le fichier route (une route définie qui pointe vers une méthode de contrôleur inexistante sera détectée à la compilation).

Un bémol toutefois: il est à noter que Play 2.0 sera incompatible avec Play 1.x, tant au niveau des API que du moteur de templating, et qu’il n’existe pas de stratégie de migration bien définie. Les changements d’API devront être gérés à la main. Pour ce qui est des templates, il faudra soit les réécrire toutes (pas forcément très réaliste), soit espérer que quelqu’un fasse un module pour pouvoir utiliser le moteur de templating basé sur Groovy avec Play! 2.0. Les projets existants sous Play 1.x risquent de ne pas être migrés vers la version 2.0, mais combien de temps la branche 1.x sera-t-elle maintenue ? De même, Play! 2.0 propose une API Java et une API Scala. On peut se demander combien de temps ces deux APIs seront maintenues en parallèle, et si l’API Java ne sera pas dans le futur reléguée au deuxième plan.

Play! est souvent perçu comme le trublion des frameworks web, et génère souvent des réactions assez polarisées (on adore ou on déteste). Mais on ne peut que constater en étant à Devoxx qu’il jouit d’une popularité croissante en voyant le nombre talks lui sont consacrés cette année. Et l’annonce de son intégration à la stack Typesafe, qui offrira un support commercial, en est une preuve supplémentaire.

En voici un résumé, avec ma propre interprétation de ses slides et mes commentaires.

Spring est aujourd’hui un framework mature, ce qui signifie que son mode de fonctionnement et ses APIs ne changent pas . . . → Lire la suite: Les nouveautés de Spring 3.1 présentées à Devoxx]]> A Devoxx, il y a une session que je ne pouvais pas manquer: les nouveautés de Spring 3.1, par Costin Leau.

En voici un résumé, avec ma propre interprétation de ses slides et mes commentaires.

Spring est aujourd’hui un framework mature, ce qui signifie que son mode de fonctionnement et ses APIs ne changent pas à chaque nouvelle version. Cependant, le framework continue à évoluer en fonction des nouvelles technologies et tendances qui arrivent: essentiellement le Cloud Computing et les nouvelles versions de Java et Jave EE dans notre cas.

Au cours des deux dernières années, nous avons ainsi vu une explosion du nombre de plateformes sur lesquels on peut déployer son application:

• Java EE (JBoss 7, Glassfish 3, Websphere 8 )
• Tomcat 7 avec les Servlets 3.0
• Les platformes de Cloud: GAE (Jetty), Beanstalk (Tomcat), CloudFoundry (Tomcat), CloudBees (Tomcat)

Ces plateformes ont un certain dénominateur commun (l’API Servlet, en particulier), mais elles ont toutes des spécificités qui font qu’elles sont plus ou moins intéressantes en fonction du besoin et du moment (car ces spécificités changent avec le temps).

D’où l’importance d’être portable au niveau du déployement.

Commençons par un rappel historique: cette portabilité du déployement a toujours été le point fort de Spring: à l’origine, nous sommes nombreux à être passés à Spring car nous voulions pouvoir déployer la même application en développement (Tomcat) qu’en production (Websphere/Weblogic).

D’autre part, on a classiquement 4 environnements dans lesquels on déploie son application:

• Le développement
• Les tests d’intégration
• La pré-production (“staging” en Anglais)
• La production

Comment permettre à son application de se déployer de manière portable?

• JNDI est la technologie d’origine, proposée par J2EE. Bien entendu, son défaut est de ne fonctionner qu’avec un container. Dans mon expérience, elle est généralement compliquée à configurer pour les équipes de production.
• Les propriétés systèmes. C’est une solution appréciée des équipes de production, par contre en Java il nous faut un moyen d’y accéder de manière simple (ce que propose Spring).
• Des “application contexts” Spring différents. Une solution “pure” Spring qui est très répandue.
• Les “PlaceHolder” de Spring (avec le tag), qui est une amélioration de la méthode précédente.

Spring 3.1 vient ajouter une nouveauté: les profils de beans. On peut grouper les beans par type d’environnement cible, par exemple “dev”, “test”, “prod”.

• Typiquement on peut avoir deux beans avec l’id “dataSource”, qui sont instanciés en fonction du profil: une dataSource de “dev” et une dataSource de “test”.
• Cette configuration n’est pas nécessairement en XML, rappelons que Spring peut maintenant être configuré en Java (avec des annotations), ce qui permet plus de liberté dans ce cas.

Ces profils peuvent être activés via une configuration XML, ou via une API Java: il faut donc activer le bon profil au démarrage, par exemple en lisant une variable d’environnement.

Lors de la conférence, Costin a fait un sondage: la moitié des gens utilisent la configuration XML, la moitié via Java. Précisons, pour les gens qui croient encore que Spring ne se configure que par XML, que cette configuration “pure Java” est inclue dans Spring depuis 4 ans.

Cette configuration Java est généralement plus concise à utiliser pour de la configuration d’infrastructure: la définition de votre data source, de votre gestionnaire de transaction, etc… Elle est également plus puissante, car on peut plus aisément faire des branchements conditionnels ou du code spécifique qu’avec du XML.

Cette première partie de la conférence, très intéressante, a cependant un défaut: on n’y a pas rééllement parlé des nouveautés de Spring 3.1. La deuxième partie de la conférence par contre, était plus orientée sur les nouveautés de cette version 3.1.

L’abstraction du cache

Evidemment, avec l’achat de Gemfire par VMWare/SpringSource, le support du cache dans Spring est une priorité de Spring 3.1. La bonne nouvelle c’est que cette abstraction fonctionne avec plusieurs “fournisseurs” de cache, et pas que Gemfire: Ehcache (Terracotta), ConcurentMap (implémentation basique mais utile pour les tests), Redis (base NoSQL également sponsorisée par VMWare). D’autre part, des implémentations Infinispan (JBoss) et Websphere eXtreme Scale (IBM) sont en train d’être contribuées. Cette fonctionnalité est particulièrement importante pour moi:

• La JSR Cache commence à redémarrer après des années de stagnation: c’est donc intéressant d’avoir quelque chose de déjà utilisable.
• Dans un contexte “Cloud”, qui implique des applications multi-tenantes, avoir un cache distrbué est absolument essentiel.

Support des Servlets 3.0

Spring 3.1 va supporter l’API Servlet 3.0, avec Tomcat 7 ou GlassFish 3, tout en préservant la compatibilité Servlet 2.4.
On peut donc maintenant configurer son application Web sans fichier web.xml

Au niveau de Spring MVC, cela apporte la gestion des requêtes HTTP asynchrones. Cette fonctionnalité est particulièrement importante pour pouvoir monter en charge lorsqu’on a beaucoup de clients, et que l’on veut faire une application Web moderne, avec beaucoup d’appels Ajax (dont certains peuvent être asynchrones).

Au niveau de Spring MVC REST, un refactoring complet a été réalisé. Costin nous promet de meilleures performances, une API plus propre pour les utilisateurs avancés, tout en restant backward compatible.

A ce sujet, deux nouveautés sur l’annotation @RequestMapping sont intéressantes:

• “consumes”, pour indiquer le type de media consumé (le “content-type header”)
• “produces”, pour indiquer ce que l’on produit

On peut par exemple avoir la configuration suivante:
@RequestMapping(value="/foo", consumes="application/pdf")

Mises à jour de librairies

Au niveau de JPA, on peut désormais avoir le package scanning sans fichier persistence.xml, ce qui simplifie les applications avec une seule persistence unit.

Spring 3.1 va supporter nativement Hibernate 4.0, avec en particulier des packages spécifiques en fonction des versions (org.springframework.orm.hibernate3 et org.springframework.orm.hibernate4).

De même, Spring 3.1 supporte Quartz 2.x (nombreux changements dans l’API Quartz 2.0/2.1), avec compatibilité Quartz 1.5. D’où l’importance d’un système d’abstraction de la configuration, afin de pouvoir monter de version facilement.

Spring 3.1 supporte Java 7

• Utilisation au mieux de Java 7 si il est disponible, sinon Spring utilisera Java 5 ou 6 (oui Spring 3.1 est toujours compatible Java 5)
• Support de JDBC 4.1, en particulier pour JdbcTemplate
• Support de la nouvelle API Fork/Join arrivée avec Java 7

Cette dernière nouveelle concerne la programmation concurrente dans le contexte actuel: nous avons en effet de plus en plus de cores sur nos machines, mais ils sont généralement moins puissants. Donc si on n’utilise pas tous ces cores de manière optimale, les performances sont moins bonnes que sur certaines “vieilles” machines.
Spring permet donc d’avoir des pools d’objets spécialisés, qui “comprennent” l’API fork/join et s’optimisent automatiquement en fonction du nombre de cores disponibles sur le serveur.
Dans un environnement “cloud” cette fonctionnalité prend tout son sens: on peut rajouter ou enlever des cores en fonction des besoins, il est donc nécessaire d’avoir une application capable de s’optimiser automatiquement en fonction de ces changements.

L’avenir et Spring 3.2

Peu d’informations sur Spring 3.2, si ce n’est que le focus sera sur les technologies suivantes:

• Java EE 7
• JCache (JSR 107)
• JMS 2.0
• Bean Validation 1.1
• JPA 2.1
• JSF 2.2

De l’autre coté des serveurs les utilisateurs raffolent de ces applications enfin ergonomiques et qui fonctionnent sur . . . → Lire la suite: Tempête sur les RIAs]]> Ceci n’est pas un billet de fond mais un appel à commentaires :

• Adobe se désengage plus ou moins en douceur de Flex,
• MS va bientôt arrêter le support Silverlight,
• Google ne proposera jamais de support sur GWT.

De l’autre coté des serveurs les utilisateurs raffolent de ces applications enfin ergonomiques et qui fonctionnent sur les vieux coucous des services administratifs du CAC 40 équipé du bon vieil IE.

Que devons-nous faire en phase de choix :

• Revenir à du JS le temps que la tempête passe ?
• Miser sur la communauté pour assurer l’avenir de Flex et de GWT ?
• Miser sur les alternatifs : Vaadin,…?
• Traverser la tempête vitesse grand V et mettre du HTML5 partout ?

A vos commentaires.

Impliqué dès le début dans le projet, c’est avec enthousiasme qu’Ippon Technologies s’est engagé à devenir l’un des premiers sponsors de l’événement.

Le projet est en cours, mais vous pouvez déjà compter sur . . . → Lire la suite: Ippon Technologies sponsor de Devoxx France!!]]> LA grande nouvelle du jour est donc la tenue de Devoxx France dans 5 mois, du 18 au 20 Avril 2012 !

Impliqué dès le début dans le projet, c’est avec enthousiasme qu’Ippon Technologies s’est engagé à devenir l’un des premiers sponsors de l’événement.

Le projet est en cours, mais vous pouvez déjà compter sur une présence importante d’Ippon Technologies à l’événement: en tant que partenaire et sponsor de longue date des événements de la communauté Java en France, Ippon réaffirme une fois de plus son engagement dans notre plate-forme préférée!

Cette annonce, ainsi que la participation d’Ippon Technologies à l’événement, a été faite ce matin lors de la keynote d’ouverture de Devoxx 2011.

Pour ceux qui auraient participé à l’ESA Mars 500, et donc qui n’auraient pas attendu avec impatience Devoxx 2011: il s’agit tout simplement de la plus grande conférence Java en Europe, avec 3200 personnes et les speakers les plus prestigieux.

Ippon Technologies a d’ailleurs envoyé une délégation de 6 de ses consultants sur place, qui vont vous tenir au courant des dernières nouveautés via ce blog, notre compte Twitter et notre compte Facebook: pour tous ceux qui n’ont pas eu la chance d’aller à Anvers cette année, cela donnera un avant-goût de Devoxx France! Dépêchez-vous de vous inscrire, il ne reste plus que 5 mois!

Nous verrons comment est structurée la mémoire d’une JVM et comment allouer de l’espace en dehors de la Heap ?

Et ce, dans le but de pouvoir conserver les données en mémoire même pour . . . → Lire la suite: Java : Accès directs à la mémoire (off-Heap)]]> La zone mémoire la plus connue d’une JVM est la heap mais ce n’est pas la seule zone de stockage disponible.

Nous verrons comment est structurée la mémoire d’une JVM et comment allouer de l’espace en dehors de la Heap ?

Et ce, dans le but de pouvoir conserver les données en mémoire même pour les applications les plus consommatrices.

Points abordés :

• Quelles sont les méthodes pour instancier de la mémoire hors heap
• Les cas d’applications (Cache, Memory Mapped File)
• Performances
• Problèmes rencontrés

Introduction et théorie

Voici les différentes zones que l’on peut retrouver dans un process Java :

Process Java

On y trouve des zones techniques : JVM, OS.

Des zones de stockage de données : Mémoire Heap et native.

La zone d’échange entre la JVM et l’OS : Librairies.

La gestion de la memoire Java est parfois assez déroutante pour les débutants : les paramètres de gestion les plus connus sont ms et mx qui régissent la taille de la Heap alors que nous venons de voir que ce n’est pas la seule zone mémoire d’une JVM.

Java nio a introduit le principe de mémoire off-heap (java 1.4). Java 7 l’a étendu (JSR-203/NIO2).

Les objets concernés sont les ByteBuffers (java.nio.ByteBuffer) avec allocation directe (maximum de  2 Go par buffer).
Concrètement il s’agit d’un tableau de Bytes qui sera stocké dans la mémoire native.
La nature même du stockage (sous forme binaire) impose une sérialisation/désérialisation des objets.

Tout d’abord le tableau suivant montre pourquoi il faut privilégier la mémoire aux autres types d’accès.

Comparaison des coûts de lecture en fonction du type de mémoire

La conclusion semble évidente : pour des raisons de performances, il faut privilégier la mémoire locale à tout autre type de stockage.

Gabarge Collector et problématiques

Longtemps la taille maximale allouée à une JVM a été limitée par différents facteurs :

• Architecture 32 bits du processeur.
• Système d’exploitation hébergeant la JVM (taille maximale d’un processus, maximum de RAM supportée)

Mais aussi, et c’était souvent le premier seuil atteint, par le comportement du Garbage Collector.

Il s’agissait de trouver le meilleur ratio entre taille de la Heap et péjoration des performances dues aux traitements du Garbage Collector.
De même, bien que plus rare que dans les langages sans gestion automatique de la mémoire, un programme Java n’est pas à l’abri des fuites mémoires.

C’est pourquoi, malgré la multiplication des architectures et OS 64 bits, cette barière n’a que peut évoluée depuis les débuts de Java.
On peut la fixer à 3-4 Go.

Conscients de cette limite, les éditeurs tentent de réagir.

Oracle à introduit le collecteur G1 (Garbage first) en version 6 de Java SE.
Ce collecteur a pour but de réduire les temps de passage du GC.

Azul System, s’est aussi positionné, avec la Zing Virtual Machine (Pauseless Garbage Collection).

En attendant, il est tentant d’utiliser le stockage hors heap dans des applications Java.

Mémoire off-heap

Une belle définition sous forme de lapalissade pourrait être : « tout ce qui n’est pas dans la heap est off heap ».

Tout d’abord voyons comment est structurée la mémoire dans la JVM

A – Zones méthodes (Method Area)

Cette zone est essentiellement alimentée par le classloader.
Quand la JVM charge une classe ou une interface, elle place les informations nécessaires dans cette zone.
Cette zone est éligible au Garbage Collector. Quand une classe passe hors scope elle sera collectée lors du prochain passage du GC.
Cette zone est partagée (accessible à tous les process de la JVM).

1 – Pool constantes :

Contient toutes les constantes définies par l’application :

Littérales : int, long, float, double ou bien String.
Références vers les types, les champs et les méthodes.

2 – Code méthode :

Implémentation (bytecode) de toutes les méthodes utilisées par la JVM.

3 – Zone d’informations :

Contient différents éléments d’information sur les classes.
Champs de classe :

• Nom du champ.
• Type du champ.
• Modificateurs du champ.

Méthodes :

• Nom de la méthode.
• Type retourné.
• Nombre et type des paramètres.
• Modificateurs de la méthode.

En plus pour les méthodes non abstraites ou natives :

• Taille de l’opérande et des variables locales (utilisée pour frame stack).
• Table d’exception.

4 – Variables de classes

Les variables de classes sont partagées par toutes les instances de la classe. De plus elles ne sont pas liées à l’instanciation d’une classe mais créées au chargement de la classe.

B – Heap

Lorsque la JVM doit instancier un objet java, elle le fait dans cette zone.
On y retrouve les classes, les objets, les primitives Java.
Cette zone est nettoyée par le GC.

Cette zone est partagée (accessible à tous les process de la JVM).

NB : il y a une seule Heap et Method Area par JVM.

C – Threads

Cette zone n’est pas partagée.

Pointeur d’instruction :

Indique la ligne de code actuellement exécutée.

Java stack :

Stocke les primitives et les références.

Stocke l’état des méthodes invoquées (non natives) par le thread, l’état comprend les variables locales à la méthode (ThreadLocal), les paramètres d’appel ainsi que la valeur retournée par la méthode.

Chaque état est stocké dans des frames (un par méthode) dont la durée de vie est liée au cycle d’appel de la méthode.

Cette zone est nettoyée par le GC.

Cette zone est parcourue par le GC afin d’identifier les objets non référencés dans la Heap.

Frames :

Trois sections compose les frames.

Piles opérande

• Pile FIFO 32/64 bits utilisée pour le stockage provisoire des variables ainsi que des calculs intermédiaires.

Données

• Références RCP (Runtime Constant Pool).
• Références vers le pool de constantes utilisées par le thread.
• Résultats des retours de méthodes.

Variables locales

• Tableau contenant les variables locales de la méthode. Soit les variables dont la durée de vie est celle de la méthode ainsi que les paramètres d’appel.

Stack Frames

Méthodes natives

A l’image des Frames l’état des méthodes natives est stocké dans cette zone.
Mais contrairement à ces dernières, l’organisation est dépendante de l’OS et de l’implémentation de la méthode native.

Création d’objets en dehors de la heap Java

L’utilisation dans un programme Java de mémoire hors heap devra répondre aux problématiques suivantes :

• Accéder à la mémoire hors heap.
• Gestion de la mémoire.
• Référencement et accès à la mémoire off-heap.

A – Java Native Access (JNA)

JNA permet l’accès aux librairies natives (dll, so) à partir de code Java uniquement (sans utiliser JNI ou du C).
Une interface java décrit les méthodes et les structures de la librairie native.
Il n’y a pas de génération de code tout se fait au Runtime.

JNA est fourni avec certaines librairies natives courantes ainsi que des classes utilitaires d’accès à la mémoire native.

Plus d’informations :

Documentation : http://www.root-me.org/fr/Documentation/Hacking/Java-native-code-injection.html
Site web : https://github.com/twall/jna

Cette librairie fournie plusieurs méthodes pour créer des objets en dehors de la heap.

int value = 12345;
int offset = 0;
int size = 128;

// on crée un objet mémory
Memory m = new Memory(1024);

// on alloue l'espace mémoire
ByteBuffer buff = m.getByteBuffer(0, size);

offset = offset + size;

// On insère l'objet
buff.putInt(value);

// RAZ de la position courante du buffer
buff.flip();

// On récupère et affiche l'objet
System.out.println(buff.getInt());

// On déclare un deuxième buffer
ByteBuffer buff2 = m.getByteBuffer(offset, size);

// On insère l'objet
buff2.putInt(value + 1);

// RAZ de la position courante du buffer
buff2.flip();

// On récupère et affiche l'objet
System.out.println(buff2.getInt());

// on libère la mémoire
m.clear();

// méthode 2
// on crée un objet mémory
// et on insère directement les objets
Memory m2 = new Memory(1024);

// On insère l'objet
m2.setInt(offset, value);

// On récupère et affiche l'objet
System.out.println(m2.getInt(offset));

// on libère la mémoire
m2.clear();

B – Utilisation de la classe ByteBuffer

L’utilisation de la mémoire native avec cette API est simple, voire transparente.
Deux méthodes de création d’un ByteBuffer sont disponibles :

1. ByteBuffer.allocateDirect()
2. ByteBuffer.allocate()

Seule la première méthode instancie un objet en dehors de la heap.

Exemple de code :

byte[] bytes = ...;
// allocate native memory to store our object
ByteBuffer buf = ByteBuffer.allocateDirect(bytes.length);
buf.put(bytes);

Remarque : Le contenu stocké doit être de type tableau de byte, ce qui explique que le contenu stocké hors heap doit être sérialisable.

Nota Bene : Ceux qui on déjà codé en C/C++ ne devront pas s’attendre a retrouver l’équivalent de malloc.
En effet les possibilités offertes sont très limitées et le plus surprenant étant qu’il n’y a pas de méthode pour désallouer un objet stocké hors heap.

Comment ça marche alors ?
En réalité une méthode de libération de la mémoire est crée automatiquement (sun.misc.Cleaner) et sera appelée par le GC lors de son prochain passage.

Conclusion :

Tout comme pour la heap, l’espace est libéré par le GC lorsque l’objet n’est plus référencé par le code.
Tout comme la heap il n’y a pas de relation directe entre le moment ou l’objet est libérable et le moment ou il est effectivement libéré.
Donc il n’y a pas de magie, les objets hors heap sont bien sensibles au GC.

Toutefois :

• Pas de phase de marquage des objets.
• Pas de phase de compaction (réorganisation de l’espace mémoire) pendant le passage du GC.
• Le nettoyage de la mémoire hors heap est donc plus rapide que son homologue de la heap.

Il est possible d’appeler la méthode de nettoyage à tout moment (encore une fois en fouillant dans les profondeurs de l’API) :

Method getCleanerMethod = buffer.getClass().getMethod("cleaner", new Class[0]);
getCleanerMethod.setAccessible(true);
sun.misc.Cleaner cleaner = (sun.misc.Cleaner)getCleanerMethod.invoke(buffer,
   new Object[0]);
cleaner.clean();

C – Autres possibilité d’allocation directe

sun.misc.Unsafe

Son utilisation est un peu plus complexe, il s’agit de la classe qui est derrière ByteBuffer.allocateDirect().
Comme son nom l’indique cette classe est unsafe et doit donc être utilisée en toute connaissance de cause. En effet l’accès à une zone mémoire non allouée provoque immanquablement le crash de la JVM.
Pour plus de sécurité les constructeurs sont privés et la méthode de classe getUnsafe() ne peut être appelée que par un Bootloader (et donc par la JVM elle même).

Heureusement il est possible de contourner cette sécurité.

Méthode de récupération d’une instance :

private static Unsafe getUnsafeInstance() throws SecurityException,
NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {
   Field theUnsafeInstance = Unsafe.class.getDeclaredField("theUnsafe");
   theUnsafeInstance.setAccessible(true);
   return (Unsafe) theUnsafeInstance.get(Unsafe.class);
}

Autres cas d’utilisation de la classe :
Cette classe permet de connaître l’adresse d’un objet stocké en mémoire.
Plus précisément la position d’un champ dans la zone mémoire allouée aux instances de la classe.

// Récupère une instance Unsafe
Unsafe unsafe = getUnsafeInstance();

// Réserve de la mémoire directe
Long allocateMemory = unsafe.allocateMemory(10);

// Récupération de l'espace d'allocation du champs code Commune
Field field = Commune.class.getDeclaredField("codeCommune");
Long offsetCodeCommune = unsafe.objectFieldOffset(field);

// On affecte une valeur à l'emplacement du champ
unsafe.putObject(allocateMemory, offsetCodeCommune, "325555");

NB : qui a dit qu’il fallait obligatoirement un setter public ?

MemoryMappedFile

Le contenu du fichier est mappé dans l’espace mémoire du process depuis le fichier source. Une fois le fichier chargé (ou une portion du fichier) tous les accès se font en mémoire.
Il en résulte des performances extrêmes par rapport aux méthodes traditionnelles qui utilisent les accès disques.

Cette méthode est la plus indiquée en cas de copie partielle ou totale d’un fichier.

File file = new File(path);

// Creation d'un memory-mapped file en lecture seule
FileChannel roChannel = new RandomAccessFile(file, "r").getChannel();

MappedByteBuffer mbb = roChannel.map(FileChannel.MapMode.READ_ONLY, 0,
   (int) roChannel.size());

// tableau de bits utilisé pour la lectre
ByteArrayBuffer bits = new ByteArrayBuffer();

while(mbb.hasRemaining()) {
   // on lit le prochain octet
   byte b = mbb.get();
   if (b == 10 || b == 13) {
      if (!firstLine) {
         // On ignore la première ligne (entête)
         firstLine = true;
      } else {
         // on affiche le contenu du fichier
         System.out.println(bits.toString());
      }

     // on passe à une nouvelle ligne
     // on réinitialise le tableau
     bits = new ByteArrayBuffer();
     } else
       // on ajoute l'octet au tableau
       bits.write(b);
}

// on ferme le canal
roChannel.close();

// on vide le buffer
mbb.clear();
...

Particularités :

• L’OS charge/décharge le contenu du fichier selon les besoins.

• Utile pour les fichiers extrêmement volumineux.

• Ou à l’inverse lorsque seul un fragment d’un fichier est utilisé.

Exemple

Mise en cache d’un extrait de la liste des communes mondiales de plus de 1000 habitants (+/- 114000) à partir d’un csv. Le code présenté a été teste avec la JVM OpenJDK 1.7 sur MAC (elle apporte un MBean de monitoring de la mémoire allouée par AllocateDirect()).

Quatre versions :

1. Une classique avec une Map
2. Une directbuffer en utilisant serialisation java
3. Une directbuffer en utilisant externalizable java
4. Une unsafe

1)

public class MemoryCache {

private Mapdata = new HashMap();

public void put(Object key, Commune object) throws IOException {
data.put(key, object);
}

public Object get(Object key) throws ClassNotFoundException, IOException {
return data.get(key);
}
…

}

2) & 3)

public class NativeMemoryCache {
private Map data = new HashMap();

public void put(Object key, Serializable object) throws IOException {
 byte[] bytes = serialize(object);
 // allocate native memory to store our object
 ByteBuffer buf = ByteBuffer.allocateDirect(bytes.length);
 buf.put(bytes);
 buf.flip();
 data.put(key, buf);
}

public Object get(Object key) throws ClassNotFoundException, IOException {
 ByteBuffer buf = data.get(key).duplicate();
 byte[] bytes = new byte[buf.remaining()];
 buf.get(bytes);
 return deserialize(bytes);
}
…

}

4)

public class NativeMemoryCacheUnSafe {

/**
* Création de la map pour stocker la clé
* ainsi que l'adresse de l'objet en mémoire native
*/
private Map data = new HashMap(120000);

/**
* Objet Unsafe pour accéder
* à la mémoire native
*/
private static Unsafe unsafe = null;

/**
* Offset de stockage dans la mémoire native
*/
private static Long offset = new Long(0);

static {
 try {
   unsafe = getUnsafeInstance();
 } catch (SecurityException e) {
   System.out.println("Exception de sécurité :" + e);
 } catch (NoSuchFieldException e) {
   System.out.println("Impossible d'accéder au champ de la classe Unsafe :" + e);
 } catch (IllegalAccessException e) {
   System.out.println("Impossible d'accéder à la classe Unsafe :" + e);
 }
}

public void put(Long key, long codeCommune, String nomCommune, double latitude,
double longitude, String codePays, String codeRegion, String codeAdministratif,
int population, String timeZone) throws IOException,
SecurityException, NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {
//Taille max d'un objet (bytes)
Long allocateMemory = unsafe.allocateMemory(400);

unsafe.putObject(allocateMemory, offset, new Commune(codeCommune, nomCommune, latitude,
 longitude, codePays, codeRegion, codeAdministratif, population, timeZone));

data.put(key, allocateMemory);
}

/**
* @param key identifiant unique de l'objet
* @return
* @throws ClassNotFoundException
* @throws IOException
* @throws SecurityException
* @throws NoSuchFieldException
* @throws IllegalArgumentException
* @throws IllegalAccessException
*/
public Commune get(Object key) throws ClassNotFoundException, IOException,
SecurityException, NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {

 Long adresse = data.get(key);
 return (Commune)unsafe.getObject(adresse, offset);
}

…

}

Résultats

used : La quantité de mémoire réellement utilisée par l’application.
committed : La quantité de mémoire qui a été réservée auprès du système d’exploitation.

Paramètres JVM : -X:+AggressiveHeap

Test 1.

Test 2.

Test 3.

Test 4.

Frameworks utilisant l’accés direct à la mémoire

Terracota BigMemory (ehcache) : stockage de données dans la mémoire native
Coherence : Coherence propose le stockage off heap dans son cache
DirectMemory : Equivalent open source de Big Memory
Huge collections : Framework permettant de manipuler de grande collection en utilisant la mémoire native

Références

Java virtual machine specifications : http://java.sun.com/docs/books/jvms/
The Structure of the Java Virtual Machine : http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html

Options de la JVM relatives à la mémoire directe.

-d64
Permet de passer la JVM en mode 64bits, utile pour adresser plus de mémoire.

-XX:MaxDirectMemorySize= ou -Dsun.nio.MaxDirectMemorySize=
Permet de définir la mémoire maximale réservées pour la mémoire off heap.

-XX:+PageAlignDirectMemory ou -Dsun.nio.PageAlignDirectMemory=true
Permet de s’assurer qu’un espace de mémoire native est alignée sur une page mémoire. Avant le JDK7, une page entière (ou plus) était allouée quelle que soit la taille de l’objet (4096 octets sur une majorité d’OS).

Conclusion

L’exemple retenu n’est pas le plus favorable aux cas d’utilisation de la mémoire off-heap, c’est pourquoi il met en exergue les inconvénients de cette solution.

L’utilisation de la mémoire native est une solution à envisager si votre programme est très consommateur en mémoire et pas forcement pour les programmes affectés par les passages du GC.

Ce n’est donc pas forcement le miracle attendu dans le sens ou ne vous dispensera pas des tracas du GC.

De plus le programme consomme temporairement autant de heap qu’un programme traditionnel (creation d’objets avant de stocker off-heap).

Enfin la sérialisation est coûteuse en terme de performances (mais seuls les programmes les plus exigeants la verront comme un véritable obstacle).
C’est pourquoi, sauf à utiliser la classe Unsafe, l’utilisation de la mémoire native est moins performante que son homologue Heap.

Conditions idéales d’utilisation de la mémoire native :

• Idéal quand la volumétrie de données est très importante (> 2 Go).
• Quand les données sont stables dans le temps (sinon les données sont collectées par le GC).
• Et enfin quand les données sont sérialisables.

L’utilisation des classes comme Unsafe est très dangereuse et réclamera une longue mise au point afin d’éviter un crash de la JVM avec pour seuls indices un code retour 139 (Segmentation violation) ou 134 (Dump core).
Pour les programmes affectés par le passage du Garbage Collector, c’est une solution parmi d’autres :

1. Tuning de la JVM et du GC
2. Création d’un pool d’objets réutilisables (crées à l’avance et jamais libérés).

Le code source est disponible ici : Source

Au menu, nous vous proposons de nouvelles rubriques détaillant nos offres, nos compétences, nos références et partenaires… Ainsi qu’une mise à jour des parties recrutement et société, avec de nouvelles pages pour nos agences de Bordeaux et Nantes.

Nous avons voulu mettre l’accent sur . . . → Lire la suite: Nouvelle version du site d’Ippon Technologies]]> La nouvelle version de notre site http://www.ippon.fr est en ligne !

Au menu, nous vous proposons de nouvelles rubriques détaillant nos offres, nos compétences, nos références et partenaires… Ainsi qu’une mise à jour des parties recrutement et société, avec de nouvelles pages pour nos agences de Bordeaux et Nantes.

Nous avons voulu mettre l’accent sur l’esprit d’Ippon, notre participation aux communautés Java et agile, et nous avons intégré le site avec ce blog et nos comptes Twitter et LinkedIn, afin de permettre une meilleure interactivité avec nos visiteurs.

Au niveau technique, car nous savons que c’est ce qui intéresse avant tout les lecteurs de ce blog:

• En tant qu’experts Liferay, il était évident pour nous que  le site devait être entièrement développé et mis en page sur un Liferay 6. Nous avons réalisé quelques portlets spécifiques, ainsi que notre propre template, mais l’essentiel du site est réalisé avec les fonctionnalités standard de Liferay. Nous avons particulièrement apprécié :
  • Les nouvelles fonctionnalités de CMS proposées par Liferay 6
  • La manière dont Liferay nous permet de gérer le SEO (Search Engine Optimization), à la fois simple et puissante
• Nous sommes hébergés sur le cloud Ippon, qui est une plateforme Open Nebula (et sur laquelle nous hébergeons également nos clients qui le désirent)
• Nous avons géré tous nos développements sur la plateforme de développement interne d’Ippon: SVN et Trac en particulier. C’est la même plateforme que nous utilisons pour les forfaits réalisés dans nos locaux.

Si vous êtes encore sous IE6 il faudra attendre la semaine prochaine pour un accès dégradé.

Bonne navigation,

La semaine dernière, à l’occasion de la disparition de Steve Jobs, Geoffray évoquait l’héritage technologique que celui-ci avait apporté à la communauté des développeurs en général et Java EE en particulier. N’en déplaise aux intégristes (comme le Molah Stallman), aux grincheux . . . → Lire la suite: L’héritage de Dennis Ritchie (1941-2011)]]>

Dennis Ritchie (debout) et Ken Thompson devant un PDP-11 en 1972 Chez Bell.

La semaine dernière, à l’occasion de la disparition de Steve Jobs, Geoffray évoquait l’héritage technologique que celui-ci avait apporté à la communauté des développeurs en général et Java EE en particulier. N’en déplaise aux intégristes (comme le Molah Stallman), aux grincheux ou aux incultes, cet apport est bien réel et la micro informatique de 2011 doit beaucoup à l’Apple II, au Macintosh ou à Next Step. Evidemment quasiment toutes ces “inventions” attribuées à Jobs ne sont que du recyclage d’idées mises au rebut par d’autres (Xerox pourrait aujourd’hui être à la place d’Apple ou Microsoft), mais n’est-ce pas ce que tous les innovateurs font : aller plus haut en montant sur les épaules des géants qui les ont précédés ? Les épaules sur lesquelles Jobs est monté sont nombreuses, mais celles de Dennis Ritchie sont probablement les plus larges. Car si la micro-informatique doit beaucoup à Jobs, l’informatique en général doit encore plus à Dennis Ritchie qui nous a quitté le week-end dernier à l’age de 70 ans.

L’histoire

A la fin des années 60, Ritchie travaillait aux Bell Laboratories avec Ken Thompson au développement d’un nouvel OS : Unix. La première version du système fut écrite en assembleur, mais rapidement, ils réalisèrent qu’ils auraient besoin d’un langage de plus haut niveau pour développer la seconde version, notamment pour gérer les structures de données indispensables au différentes fonctions de l’OS. La première tentative en Fortran fut rapidement abandonnée et  Ritchie proposa de créer un  nouveau langage basé sur le language B créé par Thompson quelques années plus tôt.

Plusieurs légendes courrent au sujet du langage B : Thompson l’aurait nommé de la sorte d’après le nom de sa femme “Bonnie” ou moins romantique d’après le nom du language BCPL dont il était inspiré. J’avais pour ma part entendu raconté que le B était pour Bell. Toujours est-il que l’itération suivante s’appelerait logiquement le language C.

La langage B était interprété et comme Ritchie et Thompson avaient autant besoin de rapidité que de flexibilité, il décidèrent que le C serait compilé pour produire un code proche de la machine.

La première version du C n’était pas très différente de celle d’aujourd’hui quoiqu’un peu moins étoffée. Les types étaient déjà là ainsi que les fameuse structures de données (struct{};pour les intimes).

En résumé, C fut inventé pour pouvoir écrire un programme et ce programme était le noyau Unix, rien que ça…

En 1973, Ritchie publia un article scientifique sur le langage C et 5 ans plus tard, lui et son collègue Brian Kernighan (qui avait rédigé les premiers tutoriels sur C et qui força un peu la main de Ritchie) publièrent le classique “C programming language“.

Bell ayant laissé ouvert et accessible le code source d’Unix, il se répandit avec le C dans les université comme une trainée de poudre pour atteindre le succès qu’on lui connait.

L’héritage

Est-il besoin d’expliquer l’importance de ces deux inventions sur ce blog ? Je ne pense pas (ou alors vous vous êtes vraiment perdu). Je résumerai juste par deux schéma trouvé sur le Web :

History of programming language (sur http://civilprogrammers.blogspot.com)/

dans ce premier schéma qui présente un aperçu des principaux langages par décénie et héritage, on voit bien que tous les langages utilisés aujourd’hui ont C comme ancêtre commun et gardons à l’esprit également que leur compilateur et/ou environnement d’éxécution ont été ou sont encore écrit en C.

Historique simplifié d'Unix (Wikipedia)

Ce deuxième schéma illustre une version simplifiée de la galaxie Unix. En parcourant ce diagramme on se rend compte qu’en dehors de Windows (qui reste donc l’OS grand public le plus propriétaire mais est malgré tout développé en C), tous les autres sont basés sur Unix. Les deux premières cases du haut c’est Ritchie, la troisième colonne c’est Steve Jobs (au passage on peut voir, que Darwin, la version de BSD qui constitue la base de Mac OS X a son code ouvert (en fait open source mais avec une licence non reconnue par l’OSI)). Ainsi, si Jobs fait partie de l’héritage de beaucoup d’entre nous Ritchie fait partie de notre Héritage à tous.

C’est parfois bon de se sortir le nez le l’IDE pour se rappeler que nous avons une histoire. Car, Etre compétent ou expert techniquement ne suffit pas pour faire un bon développeur. La culture informatique doit également s’appuyer sur le passé. Comprendre la raison d’être des outils que nous utilisons et connaître leurs ancêtres est capital. Ca évite de dire des imbécilités ou de ré-inventer la roue.

“Celui qui ne connait pas l’histoire est condamné à la revivre”
K. Marx

#include <stdio.h>

main(int argc, *char argv[]){
	if(argc!=1)
		exit(1);
	else {
		char *dennis="Dennis";
		char *world="World";
		if(strcmp(dennis,argv[0])==0) {
			printf("Hello %s says %s n",world,dennis);
			printf("Good bye %s says the %s n",dennis,world);
			exit(0);
		}
	}

L’une des technologies les plus populaires dans le monde Java EE est sans aucun . . . → Lire la suite: JPA : une magie qui se mérite (retour aux sources de JPA)]]> Cet article fait partie d’une série sur les technologies incluses dans Java EE 6. Vous pouvez également lire l’article d’introduction de cette série : Java EE 6 ici et maintenant et celui sur JSF : JSF je t’aime, moi non plus

L’une des technologies les plus populaires dans le monde Java EE est sans aucun doute JPA. Il suffit de voir le nombre de livres et d’articles sur le sujet. Toutefois, si JPA est très répandu, il s’agit aussi de l’une des spécifications Java EE les moins bien maîtrisées par les développeurs et donc une source récurrente d’échecs des projets. Fort de ce constat je ne vais pas m’apesentir sur les nouveauté de JPA 2.0 dans ce post (en dehors de l’API criteria, celles-ci sont pluôt à la marge) pour me permettre de faire un retour aux sources sur JPA qui pourra profiter à certains. Ceux qui pensent maîtriser ces concepts pourraient être quand même intéressés par la fin de la’article qui traite de l’extended persistence context et de ses mérites.

Une “magie” complexe

La popularité de JPA et les échecs que cette techno engendre sont probablement liées au mélange de magie, de concepts compliqués qu’elle camoufle et de dissimulation de ces concepts au sein de frameworks destinés à faciliter son utilisation. La magie et les raccourcis offert par Spring (entre autres) permettent  de se lancer dans l’utilisation de l’outil sans avoir besoin de trop comprendre les couches sous-jacentes. Lorsque l’on arrive dans des cas concrets qui posent des problèmes, une grande partie des développeurs désinvestissent l’outil en critiquant ses limitations sans chercher à creuser plus avant. Parce que JPA nous fait sortir du confort du code pour aller nous battre avec des notions parfois mal digérés de gestion de transaction et base de données, il reste une énigme pour beaucoup. Certains développeurs pensent que le concept d’ORM en général et JPA en particulier permet de négliger SQL et les mécanismes bas niveau d’échange avec la BDD en les ramenant au rang de technologies inférieures. En pensant cela ils commettent une erreur : JPA rend l’utilisation de ces technologies plus facile et puissante mais ne nous permet pas des les occulter totalement. Il est un facilitateur pas une technologie de substitution.

Les 4 piliers de JPA

Schema Global du fonctionnement de JPA

JPA s’inscrit autour de ces 4 notions fondamentales :

• Les entités
• Les Persistence Units (au runtime on les manipulera via la classe PersistenceManagerFactory)
• L’Entity Manager (ou persistence manager)
• Les transactions

Le schéma ci-contre illustre le fonctionnement de JPA et comment ces 4 éléments fonctionnent ensemble. Pour synthétiser :

• La Persistence Unit organise les meta données qui définissent le mapping entre les entités et la base
• La Persistence Manager Factory récupère ces metas données de la Persistence Unit et les interprètent pour créer des Persistence Manager
• Le Persistence Mangager gère les échanges entre le code et la base de donnée, c’est à dire le cycle de vie des entités
• Enfin, le travail du Persistence Manager est englobé dans une Transaction. Cette dernière peut éventuellement gérer les opérations de plusieurs Persistence Managers comme un traitement unitaire.

Sans faire un cours exhaustif, il parait intéressant de faire un point sur les concepts clés liés à chacune de ces notions clés

Les transactions

Les transactions ne faisant pas stricto sensu partie de JPA, mais étant une composante indispensable au fonctionnement et donc à la compréhension de cette technologie, il est intéressant de commencer notre tour d’horizon par un rappel sur les concepts liés au transactionnel. Les transactions sont en effet aussi importantes que les mécanismes de persistence décrits plus loin. Sans elles les données échangées avec la base risqueraient d’être corrompues ou incohérente. C’est pourquoi il est important de vérifier que le périmètre des transactions soit bien défini lors de l’interaction de votre code avec la base de données.

L’objet de ce post n’est pas de faire un cours magistral sur le transactionnel, mais il me semble intéressant de rappeler quelques concepts de base puisqu’on parle de base de données et de persistence.

Retour sur les différentes APIs transactionnelles

Une transaction est un regroupement d’instructions SQL effectuant un traitement fonctionnel atomique (par exemple l’ajout d’un article dans un panier d’achat accompagné d’une décrémentation des stock pour la référence concernée). Ce regroupement est orchestré à l’aide d’instructions SQL dédiées comme : BEGIN, COMMIT ou ROLLBACK. Bien sûr, si on ne souhaite pas agir à si bas niveau on aura plutôt recours en Java à des API chargées d’automatiser la gestion des transactions pour nous. A cette fin, nous disposons de trois possibilités :

• Les transactions gérées par JDBC
• Les transactions de type Resource-local
• Les transactions gérées par  JTA

Les entité et le Mapping

JPA permet donc d’associer des objets dans notre code à des données dans une ou plusieurs bases. Les metas données du mapping (sous forme d’annotations) apportent la souplesse indispensable qui évite d’avoir un modèle de données mémoire totalement calqué que le modèle de donnée relationnel dans la base. On pourra ainsi gérer les colonnes associées à un champ (avec @column), créer une entité sur plusieurs tables (avec @SecondaryTable) ou gérer des champs ne devant pas être stockés (avec @Transient). Bien sûr la magie n’est pas absolue et il peut arriver un moment où votre structure de base de données est trop complexe pour assurer un mapping satisfaisant et où le choix de JPA peut commencer à être remis en cause. Une notion qu’il est capitale de comprendre est la persistance transitive : les associations entre entités avec les fameux @OneToOne, @OneToMany ou @ManyToMany. Le débutant en JPA rencontrera très vite ses premiers problèmes avec ces concepts. Soit parce que les associations déclencheront des chargements en cascade et créeront des grappes d’objets monstrueuses en mémoire, soit parce qu’il aura eu recours au mécanisme de Lazy loading qui peut devenir un cauchemar si on ne maîtrise pas le cycle de vie des entités et les concepts liés au transactionnel. On se reportera à la documentation des annotations JPA d’Hibernate pour avoir une liste exhaustive des possibilités de mapping disponibles dans JPA 2.

La Persistence Unit

C’est le point de départ du moteur JPA. Elle permet de lister les entités à manager et la façon dont elles sont mappées vers la base. Elle indique également le type de transaction utilisée lors des échanges avec la base. Elle est constituée à partir de trois parties :

1. Les meta données sur les entités (sous forme d’annotations, elles peuvent être surchargées par du XML)
2. Le descripteur de la Persistence Unit : le fichier de configuration Peristence.xml qui permet de configurer la connexion à la base et la nature des transactions et des paramètres spécifiques à l’implémentation de JPA utilisée.
3. La Persistence Manager Factory : Objet au runtime représentant la configuration complète de la persistence unit. Cette factory permet de créer un ou plusieurs persistence manager fournissant les services nécessaires à la gestions des entités

Mais n’oublions pas la plomberie JDBC sous JPA et la fameuse datasource, point de départ à la connexion vers la base…

JDBC et pool de connexion

JDBC reste donc la brique de base pour interagir avec la base de données et comme a priori votre application effectuera plusieurs requêtes simultanément vers la base vous avez besoin de fournir à JPA un pool de connexions JDBC. Dans un container Java EE tout cela se fait en général en définissant une data source, soit via un fichier (comme dans Glassfish ou JBoss) soit via une interface d’admin (comme dans Websphere). Cette data source est ensuite appelée via JNDI dans le fichier persistence.xml. La datasource consitue donc un pool de connexions JDBC. son rôle est de pouvoir vous fournir une connexion déjà “prête à l’emploi” (ouverte) quand vous voulez requêter la base et de faire le ménage quand un échange s’est mal passé (timeout, connexion mal fermée, etc…). Ce pool est fourni avec votre serveur d’application. exemple de data source JBoss :

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
	<local-tx-datasource>
		<jndi-name>DefaultDS</jndi-name>
		<connection-url>jdbc:hsqldb:/Data/hypersonic/localDB</connection-url>
		<driver-class>org.hsqldb.jdbcDriver</driver-class>
		<user-name>sa</user-name>
		<password/>
		<min-pool-size>5</min-pool-size>
		<max-pool-size>20</max-pool-size>
		<idle-timeout-minutes>0</idle-timeout-minutes>
	</local-tx-datasource>
</datasources>

La plupart des containers légers permettent de faire la même chose, quasiment tous fournissent un gestionnaire de Pool JDBC. Pour les utilisateurs de Spring, il y a dans le framework de quoi déclarer un bean Datasource auquel on pourra adjoindre le pool JDBC de son choix. Je vous laisse le soin de lire cette doc croustillante qui fourmille de trolls vintage sur Java EE, (heu… pardon J2EE). Toute pique mise à part, Spring sera très utile pour gérer cet aspect ainsi que les problématiques transactionnelles dans un environnement Java SE, l’alternative étant de créer ce pool dans votre code. Quoiqu’il en soit, on se gardera bien de définir sa connexion JDBC dans le fichier persistence.xml car celle-ci ne permet pas (en standard) de choisir la nature du pool utilisé. Ainsi si votre implémentation JPA est hibernate, déclarer votre connexion JDBC dans persistence.xml vous amènera à utiliser le pool de connexion Hibernate par défaut qui n’est pas recommandé en production. Des propriétés propres à Hibernate permettent dans persistence.xml d’activer d’autres gestionnaires de pool fournis par le framework comme C3PO ou Proxool. Ces gestionnaires sont également peu recommandés, on essaiera d’utiliser en priorité le gestionnaire de pool du serveur d’application.

Le fichier persistence.xml

Là non plus je ne rentrerai pas dans les détails de la configuration du fichier de persistence. Je donnerai juste deux versions de la même unité de persistence. L’une avec une gestion du transactionnel et de la datasource au niveau container :

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
        <persistence-unit name="myPu">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<jta-data-source>java:/DefaultDS</jta-data-source>
		<properties>
                        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
		</properties>
	</persistence-unit>
</persistence>

La persistence unit définie dans ce fichier exploite la Datasource définie plus haut. Elle utilise Hibernate comme implementation JPA d’où la propriété hibernate.dialect propre à cette implémentation. La deuxième PU, définie une connexion et un pool JDBC géré en local dans l’application (en l’occurence par Hibernate)

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
	xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
	<persistence-unit name="myPu" transaction-type="RESOURCE_LOCAL">
	<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<properties>
                        <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
                        <property name="javax.persistence.jdbc.user" value="se" />
			<property name="javax.persistence.jdbc.password" value="" />
                        <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:/Data/hypersonic/localDB" />
			<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
		</properties>
	</persistence-unit>
</persistence>

Spring propose une configuration en partie propriétaire dans son fichier de configuration pour la Datasource, puis dans persistence.xml, ce qui n’est pas toujours très clair. Comme on parle ici de Java EE , on se reportera à la documentation du Framework printanier qui fait pousser le XML,  pour plus d’informations sur ce dernier.

La gestion des persistence managers

La aussi il y a plusieurs possibilités pour gérer le cycle de vie des persistence manager JPA :

1. Géré par l’application dans le code en créant des instances via le Persistence Manager Factory
2. Géré par un framework du type Spring, Seam  (si on on est sur un serveur léger). Cette solution est techniquement équivalente à la première mais vous décharge d’avoir à gérer les instanciations
3. Dans le cas d’un serveur Java EE, ceux-ci sont gérés par le container ce qui permet par exemple de partager les mêmes persistence units entre plusieurs war au sein d’un même EAR

Le persistence manager Factory

Le chargement de la persistence unit (par le serveur ou l’application) donne lieu à la création d’un objet immuable : le persistence manager factory (ou entity manager factory) qu’on va récupérer automatiquement dans un context Java EE  via :

@PersistenceUnit
private EntityManagerFactory pu;

si vous devez le faire à la main (sans un container ou framework qui le fait pour vous) cela donnera

EntityManagerFactory entityManagerFactory=Persistence.createEntityManagerFactory("my_pu");

Le code précédent bootstrap JPA et déclenche la lecture du Persistence Context “my_pu”. Ce code est comme on s’en doute extrêmement coûteux, aussi on fera en sorte de ne lancer qu’au démarrage de l’application. On travaillera rarement avec l’EntityManagerFactory et on préferera demander au container directement un EntityManager.

Au coeur du Persistence manager

Le persistence manager (ou entity manager, la littérature utilise l’un ou l’autre) est l’API responsable de gérer le cycle de vie des entités JPA. Au delà des échanges explicites avec la base de données,  il est en charge de vérifier l’état des entités qu’il manage pour propager les modifications automatiquement vers la base et gérer le cache  de niveau 1 permettant d’optimiser les accès SQL. Pour l’obtenir à partir du container on utilisera

@PersistenceContext
private EntityManager em;

si on veut le faire à la main (après avoir récupéré l’entityManagerFactory avec le code ‘”à la main” précédent):

EntityManager em=entityManagerFactory.createEntityManager();

Dans ce cas gardez à l’esprit que vous devrez gérer le cycle de vie de l’entityManager vous-même.

Une fois cela fait, nous parvenons enfin au coeur de JPA avec le Persistence Manager dont les responsabilités sont les suivantes :

• Gérer les instances des entités : l’API du Persistence manager permettent de gérer les entités. Cette API dispose des méthodes pour créer, chercher, requêter, mettre à jour et détruire les instances des entités. Ce faisant, il gère les quatre états possibles pour chaque objet entité : transient, persisté, détaché et détruit. (c.f. le schéma sur le cycle de vie ci-dessous)
• Maintenir le context de persistance (Pesistence Context en VO) : Le contexte de persistance correspond à un cache mémoire des objets entité qui ont été chargés via le persistence manager. C’est le point d’entrée pour l’optimisation des performances dans la technologie JPA. vous le connaissez probablement aussi sous le nom de cache de premier niveau. Notez aussi que le terme Persistence Context est aussi parfois utilisé à la place de Persistence Manager (ou Entity Manager ) bien que ce ne soit pas exactement la même chose.
• Réaliser des contrôles automatiques des objets managés (dirty checks dans le texte) : l’état des objets présents dans le contexte de persistance est automatiquement surveillé pendant toute la durée de vie de ce dernier. Quand un événement de “flush” intervient sur le persistence manager, les modifications detectées par ce mécanisme sont poussées vers la base de données  sous forme de de commandes SQL Lorsque une instance d’entité entre dans l’état “détaché” (detached) ses modifications ne sont plus surveillées.

Le persistence manager travaille à plus haut niverau que le SQL. Grace aux annotations de mapping, il comprend que les données transitant depuis la base ont une structure objet (l’entité) et que cette structure à un cycle de vie (voir ci-contre).

Scoper le persistence context : une approche trop souvent négligée

Le persistence Manager (et par association le contexte de persistence) est souvent victime d’une méconnaissance des développeurs qui le pensent lié à la connexion avec la base ou à la durée de vie d’une transaction.  Cette erreur provient principalement des architectures stateless dont le framework Spring a fait la promotion depuis ses débuts. A cause de cette vision simpliste et restrictive, beaucoup de développeurs considèrent comme une mauvaise pratique (voire ignorent complètement) le fait de laisser ouvert le persistence manager pour une durée supérieure à une transaction ou une requête HTTP et correspondant à un cas d’utilisation de leur application. En fait le persistence manager est bien plus polyvalent que l’approche hyper partielle et pauvre prêchée par Spring. Oui, il peut être stateful (le mot est lâché), et donc laissé ouvert le temps de réaliser un cas d’utilisation complet (plusieurs écrans et actions de l’utilisateur). Contrairement à ce qu’on pourrait craindre, le persistence manager ne laissera pas la connexion vers la base ouverte tout le temps de sa durée de vie mais saura se reconnecter de manière transparente si le besoin s’en fait sentir.

Le mauvais réglage du scoping du Persistence Manager est la cause principale des critiques adressées à JPA. Avoir recours à des outils ou patterns qui ne permettent que de l’associer à la requête HTTP ou à la transaction en cours amène les développeurs à bricoler des solutions de contournement qui sont autant de mauvaises pratiques : comme le hideux pattern Open Session in view, une redéfinition du mapping JPA pour mettre en Fetch.Eager des associations qui auraient du rester lazy ou du requetage HSQL en pagaille pour  récupérer la grappe d’objets nécessaire pour traiter la requête et ses suites (comme des échanges Ajax par exemple). Comme je l’ai écrit dans de précédents articles, si Spring a été un apport précieux pour la mise en place de bonnes pratiques en terme d’architecture, on atteint là ses limites qui sont liées à des choix idéologiques de ses concepteurs qui n’ont autorisé pendant très longtemps qu’une approche purement stateless des architectures.

Ce qu’on doit faire pour que le persistence manager ait une durée de vie supérieure à la requête HTTP, c’est le gérer en mode stateful. C’est cette approche qui permettra de gérer un scope conversation comme le fait Seam 2 depuis 2006 et comme le propose CDI en standard dans Java EE 6. Cette approche nécessite de faire attention où le persistence manager est stocké, car il ne doit pas être dans un scope partagé (scope application par exemple) puisqu’il n’est pas thread safe. Voyons comment Java EE 6 gère ce mécanisme.

Le peristence context étendu

Depuis Java EE 5,  nous avons la possibilité de créer un persistence context étendu. Comme dit, plus haut, c’est un persistence context qui reste actif au dela de la transaction (mode par défaut du persistence context).

Avoir recours à un Persitence context étendu :

• Permet de gérer proprement le lazy loading des entités ou collections associées
• Evite d’avoir à merger des entités détachées pour les synchroniser avec la base
• Vous assure de n’avoir qu’une seule référence à un objet pour un id d’entité donné
• Fonctionne avec les mécanisme d’Optimistic Locking pour supporter les unités de traitement à durée de vie longue (l’annotation JPA @Version est très utile pour ce dernier point)

Le persistence context étendu doit donc résider dans un scope stateful, et non partagé. La session ou la conversation pourraient faire l’affaire, mais la gestion de son cylce de vie resterait un peu fastidieuse. C’est pourquoi, la meilleure place pour le gérer est de le placer au sein d’un EJB Session Sateful (Stateful Session Bean ou SFSB).

On ne va pas trop entrer dans les détails des EJB ici (je garde cela pour mon prochain post), il faut juste savoir qu’un SFSB est géré par un container spécifique qui n’a rien à voir au conteneur servlet. Notre Bean a donc un cycle de vie indépendant des scopes servlet mais pourra être manipulé depuis ces fameux scopes soit en étant injecté via @EJB, soit, encore mieux en étant injecté ou directement utilisé via CDI. Le persistence context étendu ainsi utilisé ne sera fermé que lorsque le SFSB sera recyclé.  Nous reviendrons sur tout ça dans un post ultérieur. Pour le moment voici un petit exemple que j’ai emprunté à Adam Bien .

@Stateful
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
@Named
@ConversationScoped
public class OrderGateway{

  @PersistenceContext(type=PersistenceContextType.EXTENDED)
  EntityManager em;

  private Load current;

  public Load find(long id){
    current = em.find(Load.class, id);
    return current;
  }

  public Load getCurrent() {
    return current;
  }

  public void create(Load load){
    em.persist(load);
    current = load;
  }

  public void remove(long id){
    Load ref = em.getReference(Load.class, id);
    em.remove(ref);
  }

  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
  public void save(){
    //nothing to do
  }
}

La ligne 1 fait de notre classe un SFSB (EJB Stateful), la deuxième ligne désactive le support transactionnel sur l’EJB en question, la ligne 3 fait que la version CDI de cet EJB pourra être utilisé dans une page JSF via l’expression language. Et la quatrième stock le composant CDI dans le scope conversation.

On voit que dans le SFSB on inject un entity manger étendu en ligne 7. Diverses méthodes permettent de chercher, créer et supprimer des entités et en ligne 31 on annote une methode save() avec l’attribut REQUIRES_NEW qui va créer une transaction et la fermer dans la foulée commitant ainsi toutes les modifications effectuées (rappelez-vous l’entity manager empile les  modification jusqu’à ce qu’une transaction lui permette de pousser ces modifications). Ce scénario simplifié permet d’imaginer les possibilités offertes par l’extended persistence context.

Conclusion

L’empilement de technologies masquées par JPA  constitue à la fois l’origine de son succès et la principale raison des critiques que la spécification essuie. Les cas d’utilisations restreints mis en avant par Spring en ne permettant que de concevoir des architecture stateless pour les services, sont également à l’origine de pas mal de galères sur JPA. Pour utiliser cette technologie au mieux je ne vous donnerai que 3 conseils :

• Apprenez Java EE 6, ça ouvre des horizons.
• Si vous ne pouvez pas travailler avec Java EE, utilisez Seam 2 qui marche très bien sur des conteneurs léger type Tomcat et qui reprend ces concepts.
• Lisez la doc de JPA (vous pouvez commencer par ici) et non pas la version Springifiée de celle-ci.

Bibliographie 

Cet Article s’appuie sur les livres suvants

• Seam In Action écrit par Dan Allen
• Java Persistence with Hibernate par Christian Bauer et Gavin King
• Real World Java EE Patterns, Rethinking the best practices  et  Real World Java EE Night Hacks par Adam Bien

Nous allons utiliser un générateur de code (www.springfuse.com) pour réaliser notre application depuis un schéma de base de données.

Vous pouvez bien entendu utiliser votre propre schéma de base de données, mais pour . . . → Lire la suite: JSF dans le Cloud en 30 minutes]]> Cet article vous propose, en environ 30 minutes, de réaliser et déployer dans le cloud une application JSF2/Spring Webflow/Spring/JPA.

Présentation de l’application

Nous allons utiliser un générateur de code (www.springfuse.com) pour réaliser notre application depuis un schéma de base de données.

Vous pouvez bien entendu utiliser votre propre schéma de base de données, mais pour l’exemple nous nous baserons sur le schéma de l’application Tudu Lists, qui est l’application d’exemple du livre “Spring par la pratique”.

L’application générée va utiliser les dernière technologies disponibles actuellement:

• JSF 2 avec PrimeFaces, qui est aujourd’hui le meilleur jeu de composants JSF à notre avis
• Spring Web Flow pour gérer la navigation entre les pages
• Spring Security pour gérer la sécurité
• Spring pour gérer la configuration de l’application, les transactions, la couche métier…
• JPA avec Hibernate pour gérer la couche de persistence

Cette application sera déployée dans le “Cloud”, en occurrence sur la plateforme CloudBees. L’application fonctionnant sur un socle Tomcat “standard”, elle pourrait être déployée sur d’autres Clouds sans modification, par exemple sur Jelastic. Etre indépendant du vendeur de Cloud est particulièrement important pour la pérennité de votre application, ainsi que pour la bonne maîtrise de son coût.

Création de l’application dans CloudBees

Inscrivez-vous sur CloudBees à cette adresse: https://grandcentral.cloudbees.com/account/signup

L’inscription est gratuite, et vous n’aurez pas à donner de numéro de carte bleue (comme c’est le cas sur d’autres plateformes, par exemple Heroku).

1. Loggez-vous sur https://grandcentral.cloudbees.com/
2. Ajoutez les services “Applications” et “Database”. (Optionnel: ajoutez également le service “New Relic”, qui vous permettra de monitorer votre application)
3. Créez une nouvelle application (dans cet exemple nommée “prime”)
4. Créez une nouvelle base de données (ici aussi dénommée “prime”)

Création de la base de données

Utilisez votre outil préféré de connexion à MySQL (dans notre cas MySQL Workbench, disponible gratuitement ici: http://www.mysql.fr/downloads/workbench/ ) et connectez-vous à la base que vous venez de créer (tous les paramètres sont disponibles via votre compte CloudBees):

Une fois connecté, exécutez le script SQL de génération de votre base de données. Vous pouvez utiliser votre propre script, dans notre cas nous prendrons la dernière version du script de création de la base Tudu Lists:

https://github.com/jdubois/Tudu-Lists/blob/master/src/main/sql/create_schema_mysql.sql

(pour avoir le fichier directement, cliquez sur “raw” en haut à droite du fichier).

Exécutez ce script: votre base de données est prête!

Génération de l’application

Connectez vous sur http://www.springfuse.com/

Afin de générer votre application:

• Dans la partie “Database”, choisissez “Reverse your own database” et renseignez les paramètres de la base MySQL que vous venez de créer.
• Laissez les autres paramètres par défaut, en particulier celui vous proposant le type d’application à générer

Le site va ensuite vous proposer d’exécuter un commande Maven de ce type:

mvn -U archetype:generate -DarchetypeGroupId=com.springfuse.archetypes -DarchetypeArtifactId=quickstart -DarchetypeVersion=3.0.60 -DgroupId=fr.ippon.demo.prime -Dpackage=fr.ippon.demo.prime -DartifactId=prime -Dversion=1.0.0 -DfrontEnd=jsf2Primefaces -Demail= -DjdbcGroupId=mysql -DjdbcArtifactId=mysql-connector-java -DjdbcVersion=5.1.17 -DjdbcDriver=com.mysql.jdbc.Driver -DjdbcUser=jdubois-prime -DjdbcPassword=##### -DjdbcUrl=jdbc:mysql://ec2-174-129-9-255.compute-1.amazonaws.com/prime -DinteractiveMode=false -DarchetypeRepository=http://maven2.springfuse.com/
 cd prime

Une fois ces commandes exécutées, vous avez créé votre application. Il vous reste ensuite à faire la génération de votre code à partir de la base de données:

mvn -f springfuse.xml generate-sources

Félicitations, votre application est générée! Vous pouvez d’ailleurs la tester en local en tapant:

mvn jetty:run

Déploiement dans le Cloud

Dans le pom.xml de votre application, nous allons rajouter le plugin CloudBees.

Dans la section nommée “RESPOSITORIES”, ajoutez un nouveau plugin juste après celui nommé “Codehaus Snapshots” (ligne 774):

 <pluginRepository>
     <id>bees-plugins-snapshots</id>
     <url>http://repository-cloudbees.forge.cloudbees.com/public-snapshot/</url>
     <releases>
         <enabled>false</enabled>
     </releases>
     <snapshots>
         <enabled>true</enabled>
     </snapshots>
 </pluginRepository>

Puis ajoutez le plugin Cloudbees dans les plugins de “build”, tout à la fin du pom.xml (ligne 957):

 <plugin>
     <groupId>com.cloudbees</groupId>
     <artifactId>bees-maven-plugin</artifactId>
 </plugin>

Ensuite allez recherchez vos clefs d’accès à CloudBees à cette URL:
https://grandcentral.cloudbees.com/user/keys

Vous pouvez maintenant déployer votre application avec la commande suivante:

mvn bees:deploy -Dbees.appid=jdubois/prime -Dbees.apikey=##### -Dbees.secret=#####

(en mettant le bon id pour votre application, de type votrecompte/votreapplication et en remplaçant les ##### par vos clefs CloudBees).

Votre application est maintenant lancée, vous pouvez y accéder via l’URL (en mettant l’ID de votre application et votre id utilisateur):

http://votreappli.votreid.cloudbees.net/app/home

(Par exemple pour voir ma version : http://prime.jdubois.cloudbees.net/app/home)

Pour vous connecter, utilisez le login “admin” et le mot de passe “password”: SpringFuse s’est connecté à votre base de données et sécurise l’application avec les valeurs de la table “TUSER”, c’est pourquoi il ne faut pas prendre les valeurs par défaut.

Pour finir

L’application générée doit bien entendu être customisée avant d’être réellement utilisable, mais nous pouvons déjà voir que:

• L’application est performante et plutôt peu coûteuse en mémoire (environ 50 mo de RAM utilisée)
• L’interface graphique proposée par PrimeFaces, basée sur JQuery, est particulièrement agréable
• Spring Web Flow vous propose un système de navigation particulièrement efficace: gestion du bouton “back”, des onglets du navigateur, etc…
• Le fait d’être basé sur une stack standard et ouverte vous permet de migrer sans problème d’un fournisseur de “Cloud” à un autre

Ci-dessous une keynote de 1996 de présentation de WebObjects

Sans Steve et Next (il s’était fait viré d’Apple à l’époque) pas de révolution du web serverside :

Les Weblogic, . . . → Lire la suite: Nous sommes tous, experts JavaEE, des enfants de Steve Jobs ;->]]> Après les hommages officiels je tiens à faire un clin d’œil au pionnier des serveurs d’applications : Steve Jobs

Ci-dessous une keynote de 1996 de présentation de WebObjects

Sans Steve et Next (il s’était fait viré d’Apple à l’époque) pas de révolution du web serverside :

• Séparation des couches
• Modèle objet
• Load-balancing

Les Weblogic, Websphere et Jboss n’existaient pas à l’époque et sont arrivés au niveau de WebObjects que 10 ans plus tard.

L’IDE de WebObjects était ENORME avec dés 1998 du développement web WYSIWYG par exemple.

Par contre WebObjects n’a pas été un succès commercial tout comme les excellents serveurs Next : pas de stratégie commerciale d’entreprise, des pricing super élevés, une ouverture tardive vers Java.

Bref nous sommes tous, experts JavaEE des enfants de WebObjects et donc des enfants de Steve,

Merci Steve,

Geoffray

J’ai choisi de vous en présenter . . . → Lire la suite: Eclipse : améliorer sa productivité grâce aux raccourcis clavier]]> L’utilisation du clavier plutôt que de la souris permet d’être plus efficace en utilisant son IDE.
Eclipse regorge de raccourcis clavier qui peuvent nous simplifier la vie.
Il n’est pas question de tous les connaître par coeur. Il n’est pas rare d’en découvrir en allant fouiller les menus d’eclipse.

J’ai choisi de vous en présenter quelques uns qui me paraissent très utiles au quotidien.

CTRL+SHIFT+F

Effectue un formatage selon les règles configurable dans les préférences “Java>Code Style>Formatter”

public class HelloWorld {
public static void main(String[] args)
{
String name=args[0];System.out.println("Hello"
+name);
}
}

sera modifié de la façon suivante

public class HelloWorld {
        public static void main(String[] args) {
                String name = args[0];
                System.out.println("Hello" + name);
        }
}

on peut notamment régler :
* le nombre de lignes vides consécutives
* le nombre maximum de caractères par ligne (la valeur par défault de 80 n’est plus très adaptée à nos écrans)
* Où et combien insérer d’espaces dans le code.

On peut aussi utiliser ‘//’ pour forcer le passage à la ligne même en cas de formatage automatique.
Par exemple on est sûr que le code suivant restera présenté toujours sûr le même nombre de lignes.

User user = new User.Builder() //
                .withFirstName("Unknown") //
                .withLastName("Guy") //
                .withAdress("12 road of nowhere") //
                .withZipCode(01010) //
                .withCity("NowhereLand") //
                .withInterests("tennis", "music", "hiking", "java") //
                .withRoles(Role.USER) //
                .build();

CTRL+I (Indent)

C’est le petit frère du raccourci précédent mais il se limite à l’indentation du code sélectionné.
On se limite aux règles d’indentation définies dans le premier onglet des règles de formatage.

public class HelloWorld {
        public static void main(String[] args)
        {
                String name=args[0];System.out.println("Hello"
                                +name);
        }
}

CTRL+SHIFT+O (Organize Imports)

Permet de supprimer les imports inutilisés et d’ajouter ceux manquant en proposant un choix lorsque nécessaire. Très pratique aussi quand on récupère un bout de code sans les imports pour les retrouver de manière automagique.

on peut régler dans les options (Java > Code Style > Organize Imports)
* l’ordre d’import des packages (java, javax, org, com)
* le nombre d’imports sur un package à partir duquel on va importer mypackage.*
* le nombre d’imports static sur une classe à partir duquel on va importer MyClass.*

CTRL+O (Quick Outline)

Affiche la structure de la classe dans une popup, on peut également filtre l’affichage en tapant par exemple le début de la fonction que l’on veut retrouver. on peut également filtrer avec des wildcards ‘?’ ou ‘*’. Si on appuie une deuxième fois sur CTRL+O on peut également visualiser les membre hérités (aussi bien privés que publics).

ALT+SHIFT+L (Extract Local Variable)

Imaginons que l’on ait une fonction qui retourne un objet. Eclipse nous proposera d’affecter cet objet à une variable dont on va saisir le nom. le nom proposé par défaut étant la plupart du temps tout à fait satisfaisant.

treeGrid.getData();

devient

Tree data = treeGrid.getData();

ALT+SHIFT+M (Extract Method)

On sélectionne un bout de code et la fenêtre d’extraction de méthode apparait.

CTRL+SHIFT+T / CTRL+SHIT+R (Open Type/Resource)

Ces deux raccourcis jumeaux permettent de facilement ouvrir le code d’un Type (Classe, Interface ou Enum) ou d’une Ressource (xml, png, properties…).
On peut utiliser des wildcards pour effectuer sa recherche, notamment lorsqu’on ne se rappelle que d’une partie du nom recherché.
On peut également utiliser la recherche CamelCase comme expliqué dans ce post.

ALT+HAUT / ALT+BAS

Déplacer des lignes de code (en respectant l’indentation), toujours beaucoup plus rapide que le couper/coller

CTRL+K / CTRL+SHIFT+K

Rechercher dans le fichier courant la prochaine occurence du mot sélectionné.
Plus rapide que le traditionnel CTRL+F qui ouvre une popup de recherche.
Il reprend néanmoins les options sélectionnées dans cette popup (Wrap search, Case sensitive et Whole word)
Le premier raccourci effectue la recherche vers le bas. le second raccourci celle vers le haut.

CTRL+D (Delete line)

Supprimer la ligne courante, souvent plus rapide que l’utilisation d’une sélection à la souris suivie de Suppr ou Backspace

CTRL+L (Goto Line)

Super utile pour aller chercher la ligne indiquée dans une stacktrace.

CTRL+1 (Quick Fix)

En fonction du code sélectionné et/ou de l’endroit où l’on se trouve on aura un menu avec une liste d’actions possibles.

quelques exemples :
* sur une ligne où on a une erreur, une liste de suggestions de corrections est proposée
* sur un paramètre de méthode ou de constructeur, on peut alors l’affecter à un nouvel attribut de la classe.
* sur une variable on pourra la renommer.
C’est un peu le raccourci à tout faire.

CTRL+/ (Comment)

Commente ou décommente les lignes sélectionnées en les préfixant par ‘//’.

CTRL+3 (Quick Access)

Permet d’accéder rapidement aux éléments de l’interface graphique.
Par exemple, vous ne vous rappelez plus où aller chercher les options de formatage. Un petit CTRL+3, on entre Formatter et hop.

CTRL+T (Quick Type Hierarchy)

Sur une classe, donne la hiérarchie de celle-ci. Toujours pratique quand on débarque sur un projet qu’on ne maîtrise pas trop.
Par défaut les sous-types sont listés. Si on appuie une 2ème fois sur CTRL+T ce sont maintenant les super-types que l’on peut voir.

CTRL+SHIFT+I (Inspect)

En debug, ouvre une popup contenant la vue debug de l’objet sélectionné.

CTRL+SHIFT+L (Liste des raccourcis)

Ces raccourcis me sont très utiles au quotidien. Cependant les raccourcis qui vous seront très utiles ne seront certainement pas les mêmes. Chacun ayant ses petites habitudes, pas la peine d’encombrer sa mémoire avec des raccourcis inutiles. La liste des raccourcis est consultable via CTRL+SHIFT+L.
Si vous identifiez une action que vous effectuez souvent, regardez s’il n’existe pas un raccourci pour celle-ci.
Et vous quels sont vos raccourcis indispensables ?

liste des raccourcis CTRL+SHIFT+L

Le lendemain, 13 Octobre, Bertrand Pinel, notre directeur technique, . . . → Lire la suite: Speakers Ippon au JUG et à l’Agile Tour de Nantes les 12 et 13 Octobre]]> Le 12 Octobre, j’aurai le plaisir de donner ma conférence “Stateful is Beautiful” au Jug de Nantes. Si vous avez envie d’entendre parler de Java EE 6, d’extended persistence context, d’EJB et de CDI, je vous invite à vous inscrire sur le site du JUG Nantais.

Le lendemain, 13 Octobre, Bertrand Pinel, notre directeur technique,  participera à l’Agile Tour de Nantes avec sa conférence “ScrumBut, but Scrum : concilier Scrum et le mode forfait”. Les infos et inscriptions sont disponibles sur le site de l’Agile Tour.

Il ne s’agit pas ici de vous faire un article “Camel pour les nuls” mais de vous montrer que Camel met à notre disposition offre une palette d’outils facilement intégrable à nos webapps et qui peuvent nous rendre bien . . . → Lire la suite: Ayez le réflexe Camel !]]> EIP, ESB, SOA … A travers ces acronymes barbares, l’utilisation d’Apache Camel (http://camel.apache.org/index.html) peut paraître effrayant.

Il ne s’agit pas ici de vous faire un article “Camel pour les nuls” mais de vous montrer que Camel met à notre disposition offre une palette d’outils facilement intégrable à nos webapps et qui peuvent nous rendre bien des services.

Création de notre plateforme d’exécution Camel

Dans un premier temps nous allons utiliser la servlet de camel pour faciliter nos tests.

Le pom.xml

<project
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <groupId>fr.ippon.sample</groupId>
  <artifactId>customer</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <name>Camel Router Application</name>
  <description>Camel project that deploys the Camel routes as a WAR</description>
  <url>http://www.ippon.fr</url>
  <packaging>war</packaging>

  <dependencies>

    <!-- Camel Dependencies -->
    <dependency>
      <groupId>org.apache.camel</groupId>
      <artifactId>camel-core</artifactId>
      <version>2.8.1</version>
    </dependency>
    <dependency>
      <groupId>org.apache.camel</groupId>
      <artifactId>camel-spring</artifactId>
      <version>2.8.1</version>
    </dependency>

    <!-- Spring Web -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>3.0.5.RELEASE</version>
    </dependency>

    <!-- logging -->
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.6.1</version>
    </dependency>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.16</version>
    </dependency>

  </dependencies>

  <build>
    <defaultGoal>install</defaultGoal>

     <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>

      <!-- plugin so you can run mvn jetty:run -->
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>7.4.5.v20110725</version>
        <configuration>
          <webAppConfig>
            <contextPath>/</contextPath>
          </webAppConfig>
          <scanIntervalSeconds>10</scanIntervalSeconds>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

Le web.xml

Ensuite il est nécessaire de déclarer la servlet camel dans le web.xml :

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

  <display-name>Camel server</display-name>

  <!-- Spring configuration -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:/context/applicationContext.xml</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

  <!-- Camel servlet -->
  <servlet>
    <servlet-name>CamelServlet</servlet-name>
    <servlet-class>org.apache.camel.component.servlet.CamelHttpTransportServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>CamelServlet</servlet-name>
    <url-pattern>/camel/*</url-pattern>
  </servlet-mapping>

</web-app>

Le fichier de configuration Spring

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:camel="http://camel.apache.org/schema/spring"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <package>fr.ippon.sample.customer</package>
  </camelContext>

</beans>

La balise permet de définir le context qui sera utilisé par Camel (http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html).

La balise fonctionne de manière similaire à spring et se charge d’identifier les classes qui déclarent une route.

Le RouteBuilder

Nous allons maintenant créer une classe permettant de déclarer des routes (http://camel.apache.org/routes.html).

package fr.ippon.sample.customer.server;

import org.apache.camel.builder.Builder;
import org.apache.camel.builder.RouteBuilder;

public class CustomerServiceRouteBuilder extends RouteBuilder {

  /**
  * @see org.apache.camel.builder.RouteBuilder#configure()
  */
  @Override
  public void configure() throws Exception {
    from("servlet:///hello").transform(Builder.constant("Hello world"));
  }
}

Quelques explications :

• from("servlet:///hello") permet de “capturer” les requêtes provenant de la servlet camel dont le path est hello.
• transform(...) permet de transformer le message.
• Builder.constant("Hello world") ajoute la chaîne de caractères “Hello world” dans la réponse.

Le test

Pour tester notre projet, il suffit de lancer jetty via la commande mvn jetty:run et d’ouvrir un navigateur à l’URL http://localhost:8080/camel/hello

Hello word

La boîte à outils

Maintenant que nous allons nous servir de notre plateforme d’exécution Camel pour tester les nombreux fonctionnalités de Camel.

Appeler un bean spring

Au travers du composant bean (http://camel.apache.org/bean.html), Camel offre la possibilité de router un message vers un bean spring.

Pour se faire, nous allons créer un service de liste de clients.

Le POJO

package fr.ippon.sample.customer.model;
public class Customer {

  private String name;

  public Customer() {
    super();
  }

  public Customer(String name) {
    super();
    this.name = name;
  }

  public String getName() {
    return name;
  }
  public void setName(String name) {
    this.name = name;
  }
}

L’interface du service

package fr.ippon.sample.customer.service;

import java.util.List;
import fr.ippon.sample.customer.model.Customer;

public interface CustomerService {
  List<Customer> findAllCustomers();
  List<Customer> findFrenchCustomers();
  List<Customer> findEnglishCustomers();
}

Et enfin son implémentation

package fr.ippon.sample.customer.service.impl;

import java.util.ArrayList;
import java.util.List;
import org.springframework.stereotype.Component;
import fr.ippon.sample.customer.model.Customer;
import fr.ippon.sample.customer.service.CustomerService;

@Component("defaultCustomerService")
public class DefaultCustomerService implements CustomerService {

  @Override
  public List<Customer> findAllCustomers() {
    Lis<Customer> customers = new ArrayList<Customer>();
    customers.addAll(findFrenchCustomers());
    customers.addAll(findEnglishCustomers());
    return customers;
  }

  @Override
  public List<Customer> findFrenchCustomers() {
    List<Customer> customers = new ArrayList<Customer>();
    customers.add(new Customer("Jean Dupont"));
    customers.add(new Customer("Paul Durand"));
    return customers;
  }

  @Override
  public List<Customer> findEnglishCustomers() {
    List<Customer> customers = new ArrayList<Customer>();
    customers.add(new Customer("John Doe"));
    customers.add(new Customer("Adam Smith"));
    return customers;
  }
}

Ensuite il nous faut déclarer ce service dans le context spring en modifiant le fichier applicationContext.xml :

  <context:component-scan base-package="fr.ippon.sample.customer" />

Maintenant nous pouvons créer une route vers ce service avec Camel (fr.ippon.sample.customer.route.CustomerServiceRouteBuilder.configure())

from("servlet:///customer/list")
.to("bean:defaultCustomerService?method=findAllCustomers");

En relançant de serveur jetty on obtient le résultat suivant à l’URL http://localhost:8080/camel/customer/list :

fr.ippon.sample.customer.model.Customer@2b650cea,
fr.ippon.sample.customer.model.Customer@7732ece7,
fr.ippon.sample.customer.model.Customer@305f6ed4,
fr.ippon.sample.customer.model.Customer@4965391b]

Transformation du résultat

Nous allons maintenant transformer le résultat de manière à ce que la liste puisse être affichée en XML.

Camel fournit un ensemble de “data format” (http://camel.apache.org/data-format.html) permettant de transformer le rendu des messages.

Pour afficher la liste résultante en XML à l’aide de xstream (< a href=”http://camel.apache.org/xstream.html”>http://camel.apache.org/xstream.html), il suffit d’ajouter la dépendance suivante dans le pom.xml

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-xstream</artifactId>
  <version>2.8.1</version>
</dependency>

puis de créer une nouvelle route :

from("servlet:///customer/list/xml").to("bean:defaultCustomerService?method=findAllCustomers")
.marshal().xstream();

En relançant de serveur jetty nous obtenons le résultat suivant à l’URL http://localhost:8080/camel/customer/list/xml :

<list>
  <fr.ippon.sample.customer.model.Customer>
    <name>Jean Dupont</name>
  </fr.ippon.sample.customer.model.Customer>
  <fr.ippon.sample.customer.model.Customer>
    <name>Paul Durand</name>
  </fr.ippon.sample.customer.model.Customer>
  <fr.ippon.sample.customer.model.Customer>
    <name>John Doe</name>
  </fr.ippon.sample.customer.model.Customer>
  <fr.ippon.sample.customer.model.Customer>
    <name>Adam Smith</name>
  </fr.ippon.sample.customer.model.Customer>
</list>

Si maintenant nous souhaitons afficher la liste sous un format JSON, il suffit d’utiliser le data format JSON (http://camel.apache.org/json.html) et de paramétrer la route suivante :

from("servlet:///customer/list/json")
.to("bean:defaultCustomerService?method=findAllCustomers")
.marshal().json();

Nous obtenons ainsi le résultat suivant :

{"list":{"fr.ippon.sample.customer.model.Customer":[{"name":"Jean Dupont"},{"name":"Paul Durand"},{"name":"John Doe"},{"name":"Adam Smith"}]}}

Ecriture dans un fichier

Camel fournit un composant permettant de gérer les fichiers (http://camel.apache.org/file2.html).

Pour enregistrer la liste des clients sous la forme XML dans un fichier, il suffit de déclarer la route suivante :

from("servlet:///customer/list/export")
.to("bean:defaultCustomerService?method=findAllCustomers")
.marshal().xstream()
.to("file:/home/data/out/?fileName=customers.xml");

Ce composant permet également de copier automatiquement des fichiers d’un répertoire à un autre, nous évitant au passage de créer un job Quartz et un service de copie

from("file:/home/camel/data/in").to("file:/home/camel/data/out");

Envoi dans un mail

Camel fournit également un composant permettant d’envoyer des mails (http://camel.apache.org/mail.html).

Pour cela, il est nécessaire de modifier le pom :

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-mail</artifactId>
  <version>2.8.1</version>
</dependency>

et de déclarer la route suivante :

from("servlet:///customer/list/mail").to("bean:defaultCustomerService?method=findAllCustomers")
.marshal().xstream()
  .process(new Processor() {
    @Override
    public void process(Exchange exchange) throws Exception {
      exchange.getIn().setHeader("to", "waaza@yopmail.com");
      exchange.getIn().setHeader("subject", "send by camel");
  }
})
.to("smtp://host?username=sender&password=password");

Envoi sur un serveur FTP

Camel fournit également un composant permettant la communication avec un serveur FTP (http://camel.apache.org/ftp2.html).

Pour cela, il est nécessaire de modifier le pom :

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-ftp</artifactId>
  <version>2.8.1</version>
</dependency>

et de déclarer la route suivante :

from("servlet:///customer/list/ftp").to("bean:defaultCustomerService?method=findAllCustomers")
.marshal().xstream()
.to("ftp://user@host:port/directory?username=user&password=password");

Agrégation de services

Camel peut être utilisé pour réaliser de l’agrégation de service. Dans notre exemple de liste de clients, nous avons créé deux méthodes findEnglishCustomers et findFrenchCustomers.

L’idée est de proposer un seul et même service réalisant l’appel à ces deux méthodes.

Pour cela, Camel implémente le pattern multicast (http://camel.apache.org/multicast.html). Il suffit alors de créer les routes suivantes :

from("servlet:///customer/agregate/xml").multicast(
  new AggregationStrategy() {
    @Override
    public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
      Message newIn = newExchange.getIn();
      if (oldExchange == null) {
        return newExchange;
      }
      else {
        List oldBody = oldExchange.getIn().getBody(List.class);
        newIn.getBody(List.class).addAll(oldBody);
        return newExchange;
      }
    }
  }).parallelProcessing()
.timeout(500).to("direct:en", "direct:fr").end().marshal()
.xstream();

from("direct:en").to("bean:defaultCustomerService?method=findEnglishCustomers");
from("direct:fr").to("bean:defaultCustomerService?method=findFrenchCustomers");

Quelques explications :

Le principe est de dispatcher le message vers les deux routes direct:en et direct:fr qui seront en charge de lister respectivement les clients anglais et les clients français.

Le multicast permet d’agréger ensuite les résultats en suivant la stratégie décrite par la classe interne AggregationStrategy.

Conclusion

J’espère vous avoir convaincu que dans certains cas Camel peut s’avérer très utile dans nos développements.

Il est possible d’intégrer Camel simplement dans nos Web App. Je vous invite à regarder de plus près l’ensemble des composants Camel (http://camel.apache.org/components.html) ainsi que ses patterns (http://camel.apache.org/enterprise-integration-patterns.html).

Les sources sont disponibles ici

Nous avons grand plaisir à accueillir la prochaine soirée sur Scrum User Group le mercredi 5 octobre 2011, de 18:30 à…

Les inscriptions sont ouvertes à l’adresse suivante : http://www.meetup.com/frenchsug/events/33361922/

Nos salles ne sont malheureusement pas extensibles (80 places) et  je vous conseille de réserver au plus tôt.

Nos bureaux sont à Levallois : . . . → Lire la suite: Le Scrum User Group @Ippon Technologies le 05 octobre]]> Bonjour,

Nous avons grand plaisir à accueillir la prochaine soirée sur Scrum User Group le mercredi 5 octobre 2011, de 18:30 à…

Les inscriptions sont ouvertes à l’adresse suivante : http://www.meetup.com/frenchsug/events/33361922/

Nos salles ne sont malheureusement pas extensibles (80 places) et  je vous conseille de réserver au plus tôt.

Nos bureaux sont à Levallois : 90 rue Baudin – 5 ème étage – 92300 – Levallois-Perret => PLAN

Nous sommes à égale distance (5 minutes) du métro 3 (Pont de Levallois) et de la gare SNCF de Clichy-Levallois.

En espérant vous voir nombreux à cette soirée agile,

Geoffray

Puis, dans un second temps, Antoine Büsch, consultant chez Ippon nous présente un . . . → Lire la suite: Ippevent Flex avec Granite DS : Les Films]]> Ca y est ! Les vidéos de l’Ippevent du 23 juin dernier sont enfin disponibles. Dans cette session nous retrouvons tout d’abord William Drai qui nous présente les mérites de l’outil Granite DS et son apport conséquent sur les développemens Flex.

Puis, dans un second temps, Antoine Büsch, consultant chez Ippon nous présente un retour d’expérience sur l’utilisation de Granite DS lors d’un projet Flex.

Julien Dubois, directeur du pôle conseil de la société, y animera une présentation sur les thèmes de la montée en charge et des bases de données NoSQL, intitulée “Hibernate vs. le Cloud Computing”.

Pour plus de détails et pour . . . → Lire la suite: Ippon Technologies au Tours JUG]]> Après La Rochelle et Bordeaux, Ippon Technologies sera présent au Tours JUG le 21 Septembre 2011.

Julien Dubois, directeur du pôle conseil de la société, y animera une présentation sur les thèmes de la montée en charge et des bases de données NoSQL, intitulée “Hibernate vs. le Cloud Computing”.

Pour plus de détails et pour vous inscrire à la soirée, rendez-vous sur le site du Tours JUG.

Le French Scrum User Group organisait vendredi 24 Juin une soirée “DevOps, Scrum et Kanban” dans les locaux du Centre de Conférences Microsoft à Issy-Les-Moulineaux.  Je profite de ce billet pour partager avec vous mes retours sur les conférences présentées à cette occasion.

Cette session comprenait les sujets suivants :

LMAX (http://www.lmaxtrader.co.uk : plate forme de trading) va à contre courant avec son architecture et montre que l’on peut faire du XTP uniquement avec le JDK mais non sans revoir quelques idées reçues.

En effet alors . . . → Lire la suite: LMAX : 6 millions d’opérations par seconde]]>

Pour rebondir sur le challenge USI, voici un cas à part dans les architectures hautes performances et haute disponibilité.

LMAX (http://www.lmaxtrader.co.uk : plate forme de trading) va à contre courant avec son architecture et montre que l’on peut faire du XTP uniquement avec le JDK mais non sans revoir quelques idées reçues.

En effet alors que la tendance est :

1. coté hardware, à multiplier le nombre de core plutôt que leur puissance brute,
2. coté logiciel à introduire le multi threading,

LMAX est spécialisé dans le passage d’ordres de bourse ce qui suppose du temps réel pour l’affichage des cotations, un volume de transactions très important, le respect de l’ordonnancement des ordres et un temps réduit pour leur exécution.

Leur architecture est dimensionnée pour des millions d’utilisateurs, que ce soit par leur site ou bien en utilisant les API publiées.

LMAX peut gérer 6 millions d’ordres par seconde avec une machine tout à fait courante (2 CPU, 4 core à 3Ghz et 32Go RAM) et le tout en Java et sans framework supplémentaire.

LMAX est une filiale de Betfair (site de paris en ligne) et devant les difficultés de mise au point et de maintenance ils ont décidé de revoir complètement l’architecture mise en place pour construire LMAX.

Ils ont tout d’abord pensé que le multithreading serait la solution idéale.

Après les premiers tests ils ont fait le choix délibéré de ne pas recourir au multi-thread qui comporte les inconvénients suivants :

• Plus complexe à mettre en œuvre
• Plus complexe à tester
• Coût hardware plus élevé

On peut modérer ce dernier point car le nombre de cœurs va directement donner le nombre de traitements possibles comme nous le verrons par la suite.

Plus que l’architecture mise en place, se sont les observations faites qui sont intéressantes (sur Java, sur les CPU, …) et qui parfois remettent en cause tout ce que l’on pouvait penser jusqu’alors.

Leur choix d’architecture et surtout les tests de performances les ont amené à faire une analyse très poussée des CPU modernes.

Ils se sont rendu compte que ce qui est communément admis (et sans doute vrai avec les anciens processeurs) ne l’est plus du tout aujourd’hui.

Ils ont donc conçu un système en adéquation avec le fonctionnement des processeurs modernes (c’est ce qu’ils nomment « mechanical sympathy »).

Leur besoin extrême en performance les ont entraîné bien au delà des analyses habituelles.

Pour vous donner une idée on entend bien souvent la maxime suivante « disk is the new tape » sous entendu que les temps de lecture/écriture sur disque sont très pénalisants en terme de performances et que les capacités actuelles des machines (fiabilité, volume) encouragent une utilisation de la mémoire uniquement.

Pour LMAX même les performances de la mémoire principale (RAM) ne sont pas suffisantes et ils ont tout fait pour que leur code privilégie le cache du CPU (leur code est déclaré cache safe).

Comparaison des coûts de lecture en fonction du type de mémoire

Rapidement leur exigence de performance les a obligé a abandonner tout lock de ressource car synonyme de « context switch » (en basculant d’un thread à l’autre le CPU peut écraser les valeurs contenues dans le cache).

En effet en cas de lock, le système donne la main à un autre thread en attendant la libération de la ressource. Ce qui implique un changement de contexte (CPU et données) et le contenu du cache est donc susceptible d’être écrasé avant d’être de nouveau chargé.

Il ne suffit donc pas d’utiliser les caches du processeur, encore faut il comprendre et maîtriser leur fonctionnement.

En terme de méthodologies rien de révolutionnaire, bien au contraire, puisqu’ils approuvent et cautionnent le TDD ainsi que la notation UML.

Problématiques et phénomènes analysés :

• False sharing
• Memory barrier
• Context switch
• CAS
• Cache line

Leur conclusion vis à vis des méthodes existantes :

1. Les queues (java) sont coûteuses (temps de traitement et lock des ressources)
2. Le multi-threading est coûteux (contentions sur les ressources communes) et difficile a mettre en œuvre.
3. De surcroit le multi-threading n’est pas le plus efficace en terme de performances.

Évidemment leur conclusion est très liée au contexte de leur étude et leur architecture ne pourra convenir à tous.

Parmi les contraintes ont peut citer :

Les messages doivent être lus séquentiellement (un consommateur ne choisi pas ses messages)

Chaque message doit donc avoir un sens au niveau fonctionnel (et non pas un ensemble de messages).

Cerise sur le gâteau, en plus d’une transparence assez rare sur leur architecture, ils ont décidé de faire partager leur framework qui est maintenant disponible en open source LMAX Disruptor.

Ce qu’a mis en œuvre LMAX c’est une façon plus rapide de partager les données entre les threads, sans recourir aux mécanismes utilisés habituellement (variables synchronisées).

Particularités de l’architecture :

• Utilisation du pattern Disruptor
• Pas de base de données, tout en mémoire
• Pas de queuing/messaging classique
• Pas de locking

NB : l’avantage de ne pas recourir à un SGBD, en plus de n’avoir qu’un seul langage de programmation (exit SQL, EJBQL, etc.), est que donc seule une JVM est nécessaire (Java 5+). Il en ressort une architecture simplifiée sans pour autant sacrifier la disponibilité.

Pattern Disruptor

Tout l’intérêt du pattern Disruptor réside dans la façon de produire et consommer des messages stockés dans le Ring Buffer.

Les producteurs, le Ring Buffer et les consommateurs sont chacun dans des threads différents.

Les acteurs : Producteur, Consommateur

Les objets : RingBuffer, Barrier

Les stratégies : Wait, Claim

Cette structuration du code oblige a certaines adaptations.

Le traitement d’un message (le cœur du process) doit être le plus rapide possible. Si il s’agit d’un traitement long (persistance, IO, journalisation) ce traitement doit être déporté dans un process indépendant qui ne ralentira pas les autres. Ces traitements sont placés dans les consommateurs.

C’est le royaume de l’asynchronisme.

Un peu de théorie

Compare and Swap (CAS)

De nombreux processeurs modernes possèdent une instruction qui effectue une opération atomique de type comparaison et échange ou compare-and-swap (CAS) au niveau matériel.

Utile afin d’éviter l’utilisation des techniques habituelles d’accès concurrents telles que Sémaphores et Mutex.

Le principe est assez simple à implémenter en Java (ici c’est purement théorique puisque l’opération est réalisée par le CPU et non par code).

@ThreadSafe
public class SimulatedCAS {
	@GuardedBy("this")
	private int value;

	public synchronized int get() {
		return value;
	}

	public synchronized int compareAndSwap(int expectedValue, int newValue) {
		int oldValue = value;
		if (oldValue == expectedValue)
			value = newValue;

		return oldValue;
	}

	public synchronized boolean compareAndSet(int expectedValue,
			int newValue) {
		return (expectedValue == compareAndSwap(expectedValue, newValue));
	}

}

Chaque client conserve l’ancienne valeur et lorsqu’il souhaite la modifier il suffit de comparer cette ancienne valeur avec la valeur actuelle et si elle est différente c’est que quelqu’un d’autre est passé par là.

Support CAS dans la JVM

Avant Java 5, il était impossible de forcer le processeur à utiliser une instruction CAS (à moins d’utiliser du code natif).Depuis un nouveau package à été introduit “java.util.concurrent.atomic”.

Les classes associées sont AtomicBoolean, AtomicInteger, AtomicLong, et AtomicReference pour les références objet.

CAS est plus rapide qu’un lock car :

• Une seule instruction pour deux opérations (mise à jour conditionnelle)
• Pas de context switch contrairement aux locks.

Toutefois CAS doit se limiter aux opérations simples sur des objets simples (incrément d’un compteur par exemple) car il peut s’avérer très complexe à maitriser (et pas plus rapide plus que les locks).

Comparaison des temps de traitement (incrément d’un long 500 millions de fois)

Memory Barrier

Les barrières mémoires sont une instruction CPU qui permet d’isoler une partie des instructions du reste du code.

Le compilateur mais aussi le CPU peuvent réorganiser les instructions (changer l’ordre d’exécution) tant que le résultat final est le même pour des raisons de performances.

Les barrières mémoires indiquent au CPU et au compilateur que les instructions entourées de barrières ne doivent pas en sortir et ne doivent pas être réorganisées. De plus lorsque le CPU franchi une barrière il rafraichit systématiquement ces caches afin d’être certain que le code travaille avec la dernière valeur d’une données.

Le Java Memory Model précise que lorsque l’on utilise des données volatiles, alors le compilateur insère automatiquement une barrière d’écriture après une modification du champ et une barrière de lecture avant toute lecture.

Les barrière mémoire apporte donc une certaine sécurité dans le code pour un coût certes non négligeable mais inférieure à un lock.

C’est peut être la réhabilitation/redécouverte du mot clé volatile en Java.

Cache Line/padding/false sharing

La mémoire est stockée dans le processeur dans ce que appelle des « caches lines » (blocs contigus de mémoire).

Ces blocs font de 32 à 256 octets en fonction des processeurs (64 octets est la valeur la plus courante).

Ainsi les données stockées dans ces caches ne sont pas isolées mais sont traitées par bloc, donc si deux variables sont contenues dans le même bloc alors elles sont traitées de manière commune.

Ce qui signifie qu’un lock sur une des variables bloquera obligatoirement toutes les données du bloc.

C’est ce qu’on appelle le « false sharing ».

Ce qui est acceptable pour un traitement mono-thread, l’est beaucoup moins lorsque l’on travaille en multi-threads.

Dans le cas de l’architecture mise en place par LMAX et le pattern Disruptor un des composants que l’on doit absolument protéger est le Ring Buffer et en particulier le curseur. De manière générale il s’agit des variables de type volatile.

Il existe heureusement une technique pour s’affranchir de ce problème, il s’agit du padding (remplissage).

Plutôt que de déclarer uniquement notre curseur on va déclarer tout un ensemble de variable qui ne serviront pas mais permettront de s’assurer que l’ensemble remplisse totalement la taille du cache line.

Extrait du code du RingBuffer

private volatile long cursor = INITIAL_CURSOR_VALUE;
public long p8, p9, p10, p11, p12, p13, p14; // cache line padding

Au lieu d’un seul long ce sont 8 longs qui sont déclarés soit 8*taille d’un long : 64 octets.

Sur des processeurs utilisant des blocs de 64 octets ont est assuré que le bloc n’est pas partagés par plusieurs variables sensibles (sur une JVM 32 bits).

On pourrait croire cette technique contre productive (déclarer plus de variables) que ce dont on a réellement besoin mais les tests menés tendent à prouver le contraire.

Aperçu des performances obtenues en éliminant le false sharing (http://mechanical-sympathy.blogspot.com/2011/07/false-sharing.html).

NB : Comme il n’est décidément pas simple d’obtenir le meilleur de Java, Java 7 est plus intelligent que ces prédécesseurs (en tout cas le compilateur) et élimine les variables inutilisées rendant obsolète la technique utilisée ci dessus.

Heureusement LMAX travaille déjà sur une parade (http://mechanical-sympathy.blogspot.com/2011/08/false-sharing-java-7.html) en attendant un jour que Java, à l’image du C++ et du C# pour les structures, permette au développeur de gérer les caches lines pour les structures).

Disruptor

Ring Buffer

Le Ring Buffer est l’élément central puisque c’est lui qui stocke les messages. C’est une implémentation maison des collections Java. Afin de le rendre le plus performant possible, il est déchargé de certaines opérations habituellement dévolues à ce type de structure (cycle de vie des données, …).
Caractéristiques :

• Buffer de taille fixe (tableau d’Entry).

• Si la file est pleine on remplace le premier enregistrement (principe FIFO).

Deux pointeurs sont utilisés :

Cursor : Dernière insertion/modification d’un consommateur ou d’un producteur.

Next : Premier emplacement disponible dans le Ring Buffer.

On accède à un message par son numéro de séquence (long et non Long car plus rapide).

Chaque acteur accédant au Ring Buffer possède son propre compteur (emplacement actuellement accédé du Ring Buffer) et évidemment il est possible de synchroniser un producteur et un consommateur (un acteur gère son propre compteur pour les écritures mais peut lire les autres compteurs).

Ceci permet de gérer les multiples accès au Ring Buffer.

Le numéro de séquence n’est pas le numéro de slot du Ring Buffer mais un compteur incrémenté par le producteur (il augmente toujours).

Une fois le message consommé, l’emplacement n’est pas libéré (vidé), il est simplement disponible pour un nouveau message.

Un message est considéré comme consommé seulement si un accusé de réception est transmis assurant une certaine robustesse au système.

Une fois consommé le message est sous la responsabilité du consommateur (différence avec du queuing par exemple).

Messages (Entry)

Les éléments stockés sont des Entry (classe à surcharger obligatoirement, seule une classe abstraite est fournie) qui peuvent être soit directement des valeurs, soit des pointeurs vers ces valeurs. C’est pour cela que seule une classe abstraite est fournie, l’implémentation étant trop liée au contexte du projet.

Exemple simple ou le message est un long :

public final static class ValueEntry extends AbstractEntry {
		private long value;

		public long getValue() {
			return value;
		}

		public void setValue(final long value) {
			this.value = value;
		}

		public final static EntryFactory ENTRY_FACTORY = new EntryFactory() {
			public ValueEntry create() {
				return new ValueEntry();
			}
		};
}

Consommateur :

Un même message peut être consommé par différents consommateurs en parallèle ce qui permet par exemple de gérer les logs en parallèle du traitement.

Définit comment est transmis le message : par copie ou par référence.

On peut chainer les consommateurs, ainsi un consommateur peut attendre qu’un premier consommateur ait traité la donnée avant d’intervenir (transformation, complétion du message par exemple).

L’implémentation d’un consommateur n’est pas aisé mais est facilité par la présence d’une implémentation par défaut « BatchConsumer » qui conviendra dans bien des cas.

Ainsi le consommateur implémente simplement l’interface “BatchHandler” (callback invoqué lorsqu’une nouvelle entrée est disponible), soit l’implémentation de la méthode « onAvailable(T entry) » qui sera appelée lorsqu’un nouveau message aura été déposé dans le Ring Buffer.

 /*** Callback interface to be implemented for processing {@link AbstractEntry}s as they become
  * available in the {@link RingBuffer}
  * @see BatchConsumer#setExceptionHandler(ExceptionHandler) if you want to handle exceptions
  * propagated out of the handler.
  *
  * @param AbstractEntry implementation storing the data for sharing during exchange or
  * parallel coordination of an event.
  */
    public interface BatchHandler {
    /**
     * Called when a publisher has committed an {@link AbstractEntry} to the {@link RingBuffer}
     *
     * @param entry committed to the {@link RingBuffer}
     * @throws Exception if the BatchHandler would like the exception handled further up
     * the chain.
     */
    void onAvailable(T entry) throws Exception;

    /**
     * Called after each batch of items has been have been processed before the next waitFor
     * call on a {@link ConsumerBarrier}.
     *
     * This can be taken as a hint to do flush type operations before waiting once again on
     * the {@link ConsumerBarrier}.
     * The user should not expect any pattern or frequency to the batch size.
     * @throws Exception if the BatchHandler would like the exception handled further
     * up the chain. */
    void onEndOfBatch() throws Exception;
    }

Producteur :

C’est lui qui insère les messages dans le Ring Buffer.

Son interaction avec le Ring Buffer est le plus souvent assez simple :

Effectue une demande d’emplacement libre,

Commit le message une fois valorisé, le message est alors visible de tous.

Productor Barrier :

L’objet est obligatoire pour insérer des messages dans le Ring Buffer.

Les producteurs ne dialoguent pas directement avec le Ring Buffer mais avec le ProductorBarrier.

La ProductorBarrier est créée par le Ring Buffer.

Consumer Barrier :

Obligatoire pour consommer des messages.

Un consommateur accède au Ring Buffer au travers d’un ConsumerBarrier.

La ConsumerBarrier est créée par le Ring Buffer

Consommation d’un message :

Le consommateur doit connaître le numéro de séquence avant de consommer un message.

il peut :

1. Interroger le Ring Buffer pour connaitre le curseur courant et obtenir le message par ce numéro de séquence.
2. Obtenir le prochain message disponible.
3. Gérer son propre compteur et interroger le Ring Buffer pour connaitre le nombre de messages disponibles avec un numéro de séquence supérieur (et les récupérer en masse).

En théorie les consommateurs ne font que lire les messages, toutefois il est possible pour un consommateur d’écrire dans le Ring Buffer. La condition est qu’une entrée ne peut être modifiée que par un seul consommateur.

Garbage Collecteur et Ring Buffer :

Le Ring Buffer est un tableau d’Entry.

Sa taille est fixe et allouée dès le début, la probabilité pour que l’ensemble du Ring Buffer soit contenu dans des espaces contigus est donc forte.

Le Ring Buffer permet de bénéficier du cache striding.

Les messages consommés sont remplacés par d’autres au besoin afin de limiter la consommation de la mémoire.

Les messages sont évidemment recyclés par le Garbage Collector mais pas le Ring Buffer.

Les objets ayant une durée de vie courte ou les données qui persistent tout le temps de vie d’une application ne sont pas problématique en terme de performance du Garbage Collector.

Ceux qui posent problèmes sont ceux qui peuvent survivre à un Garbage Collector pour être nettoyés ensuite.

Concrètement ce ne sont ni les variables locales ni les variables globales mais bien celles qui s’échangent entre fonctions ou entre thread.

LMAX a donc cherché à les minimiser.

Stratégies

Lorsque l’on crée un Ring Buffer on va préciser la manière dont les messages seront consommés (consommateur) et la gestion des numéro de séquence (producteur)

WaitStrategy

Stratégie utilisée par le consommateur en attente de messages postés par le producteur.

BLOCKING

Stratégie classique qui utilise un lock tant que le message n’est pas disponible, bloque le consommateur mais ne consomme pas de CPU.

C’est la stratégie par défaut.

YIELDING

Cette stratégie utilise un Thread.yield() pour rendre la main au CPU évitant ainsi de bloquer les traitements.

Cette stratégie est évidemment moins rapide mais permet de préserver les ressources.

BUSY_SPIN

On attend tant que la ressource n’est pas disponible mais sans poser de lock sur la ressource (la plus rapide mais mobilise CPU et consommateur).

ClaimStrategy

Stratégie utilisée pour récupérer le prochain numéro de séquence libre (producteur).

MULTI_THREADED : un thread pour chaque demande.

C’est la stratégie par défaut compatible avec plusieurs producteurs.

SINGLE_THREADED : La plus optimisée (un seul thread en écriture).

Gestion des erreurs :

La gestion des erreurs est particulière et surprenante.

Leur principe est le suivant : il n’y a pas d’erreur ! (les tests sont là pour adapter le code à toutes les éventualités).

Dans leur esprit une entrée (un message), ne doit pénétrer le système qu’après validation afin d’être certain qu’elle pourra être traitée correctement.

En cas de faille du système un autre prend le relai.

Leur framework ne permet pas le retour en arrière (rollback d’une transaction).

Toutefois pour les plus sceptiques il y a possibilité de surcharger la classe ExceptionHandler pour pouvoir exécuter du code en cas d’erreur de traitement d’une Entry.

NB : Seules les exceptions de type RuntimeException mettent fin au programme (après un log).

Failover :

Avec un tel système (event processing) il suffit de pouvoir sauvegarder les messages pour pouvoir les rejouer et donc rétablir une plateforme après un crash.

C’est le système retenu par LMAX. Toutefois afin d’éviter d’avoir a rejouer un trop grand nombre de messages et d’avoir un temps de rétablissement trop important il ont décider de prendre une photo (snapshot) de leur système quotidiennement (état des données en sortie) et de simplement journaliser les événements de la journée.

LMAX a plusieurs systèmes qui tournent en parallèle (3) mais dont un seul n’est réellement actif.

Chaque message est traité par l’ensemble des systèmes ce qui oblige à synchroniser les trois nœuds.

Ce système de cluster détecte en permanence si le maître est toujours actif (multicast). Un autre prend le relais en cas de défaillance.

Plus d’informations dans le Bliki de Martin FOWLER.

Remarques et problématiques :

Le pattern idéal pour le Disruptor est :

1. Un seul producteur.
2. Plusieurs consommateurs (dans des threads différents).
3. Un seul thread par CPU (si 8 cœurs alors 8 threads maximum).

Avoir un seul producteur est un gain considérable :

• Pas de contentions sur les écritures du Ring Buffer (donc pas de lock, de CAS, etc..).
• Gestion plus simple du curseur (dernier ajout) qui ne dépend que d’un seul traitement.
• Un seul thread responsable des écritures.
• Meilleure utilisation du cache CPU.

Une amélioration du Disruptor est le batching effect.

Un consommateur conserve le numéro de séquence de la dernière entrée traitée (point de référence) ainsi lorsqu’il interroge le Ring Buffer pour savoir si un nouvel élément est disponible et que plusieurs entrées ont été mises à jour alors le Ring Buffer envoie l’ensemble des séquences ce qui permet de les traiter toutes sans multiplier les interrogations du Ring Buffer.

Comment s’assurer qu’un message n’est traité qu’une seule fois en cas de multiples consommateurs ?

Nativement impossible mais avec un peu d’ingéniosité on y arrive (par exemple si on utilise deux consommateurs un premier traitera les séquences paires, l’autre les impaires) en cas de consommateurs plus nombreux on utilisera les modulos.

Dans la majorité des cas un seul Ring Buffer est nécessaire même si les consommateurs sont chainés (contrairement aux queues par exemple) par contre il faut une consumerBarrier par consommateur.

Comparaison des systèmes possibles (traitement en parallèle)

Multithreading : Lock sur les ressources partagées pour gérer les accès concurrents.

SEDA (staged event-driven architecture) : Utilisation de queues pour les ressources partagées.

LMAX : Utilisation de RingBuffer (Array non synchronisé) pour les ressources partagées.

Conclusion

Nous avons le cas d’une recherche extrême de la performance.

Heureusement que toutes les applications n’ont pas besoin de grappiller les millisecondes.

Le modèle choisi par LMAX n’est surement pas applicable à tous les cas mais il permet de faire évoluer des certitudes :

• Pour un traitement simple (un calcul) par exemple le multithreading n’est pas la solution miracle.
• Ne partager des ressources que si on ne peut pas faire autrement.

Conclusion du benchmark : moins il y a de threads, meilleures sont les performances.

Les performances ne sont pas linéaires avec le nombre de threads.

De manière globale, on peut extrapoler que les locks sont plus performants que l’utilisation des synchronized.

En fonction du nombre de threads, la meilleure technologie n’est pas la même. Ce qui milite fortement pour des tests systématiques lors du choix de la technologie la plus adaptée au contexte du projet.

Compléments :

Bliki M. FOWLER

Blog équipe LMAX

Exemple de code

Le code est là pour illustrer l’utilisation du pattern Disruptor (ne chercher pas l’utilité d’un tel code moi même je la cherche encore).

Nous avons un producteur qui va poster des messages correspondant à un chiffre de 0 à 1000.

Nous avons divisé la tache en trois :

• Un consommateur pour calculer le cube des chiffre pair.
• Un consommateur pour calculer le cube des chiffre impair.
• Un consommateur pour afficher les résultats.

Le consommateur 3 (logger) a besoin des deux autres pour pouvoir fonctionner.

Cet exemple va donc illustrer une dépendance entre des consommateurs ainsi qu’un partage des tâches entre deux consommateurs.

Enfin les consommateurs de type calcul écrivent dans le Ring Buffer le résultat de l’opération.

Code d’une Entrée

public final static class ValueEntry extends AbstractEntry {
	private long value;
	private long cubic;
	private String className;
	public long getCube() {
		return cubic;
	}

	public void setCube(long cube) {
		this.cubic = cube;
	}

	public long getValue() {
		return value;
	}
	public void setValue(final long value) {
		this.value = value;
	}

	public void setClassName(String className) {
		this.className = className;
	}

	public String getClassName() {
		return className;
	}

	public final static EntryFactory ENTRY_FACTORY = new EntryFactory() {
		public ValueEntry create() {
			return new ValueEntry();
		}
	};
}

Il y a trois champs :

1. La valeur initiale.
2. Le résultat du calcul.
3. Le nom de la classe qui va permettre d’identifier le consommateur qui a effectué le traitement.

Code du producteur

for (long i = 0; i < =1001; i++) {
  // Producers claim entries in sequence
  ValueEntry entry = producerBarrier.nextEntry();

  // copy data into the entry container
  entry.setValue(i);

  // make the entry available to consumers
  producerBarrier.commit(entry);
}

Code des consommateurs (calcul)

public void onAvailable(final ValueEntry entry) throws Exception {
  // process a new entry as it becomes available.
  entry.setCube((entry.value) * (entry.value) * (entry.value));
  StackTraceElement trace = Thread.currentThread().getStackTrace()[3];
  entry.setClassName(trace.getClassName());
}

Code du consommateur (logger)

public void onAvailable(final ValueEntry entry) throws Exception {
 // process a new entry as it becomes available.
 System.out.println("Processing entry : " + entry.getValue());
 System.out.println("Cube : " + entry.getCube());
 System.out.println("Processed by : " + entry.getClassName().toString());
}

Modification de la classe BatchConsumer

On va modifier le consommateur fourni par défaut en deux classes distinctes, l’une traitant les séquences paires l’autre les séquences impaires.

Pour le consommateur impair on commence avec un décalage

private volatile long sequence = RingBuffer.INITIAL_CURSOR_VALUE + 1;

Dans les deux consommateurs on remplace le code suivant :

for (; nextSequence < = availableSequence; nextSequence++) {

par :

for (; nextSequence < = availableSequence; nextSequence = nextSequence + 2) {

Code complet

package disruptor;

import java.util.concurrent.Executor;
import java.util.concurrent.Executors;
import com.lmax.disruptor.AbstractEntry;
import com.lmax.disruptor.BatchConsumer;
import com.lmax.disruptor.BatchHandler;
import com.lmax.disruptor.ClaimStrategy;
import com.lmax.disruptor.ConsumerBarrier;
import com.lmax.disruptor.EntryFactory;
import com.lmax.disruptor.ProducerBarrier;
import com.lmax.disruptor.RingBuffer;
import com.lmax.disruptor.WaitStrategy;

public class Disruptor {
	// Ring Buffer size
	private static int SIZE = 100;
	private static Executor EXECUTOR = Executors.newCachedThreadPool();

	// Creation of the RB with optimized claim strategy and aggressive wait
	// strategy
	private static RingBuffer ringBuffer = new RingBuffer(
			ValueEntry.ENTRY_FACTORY, SIZE,
			ClaimStrategy.Option.SINGLE_THREADED, WaitStrategy.Option.BUSY_SPIN);
	/**
	 * @param args
	 * @throws InterruptedException
	 */
	public static void main(String[] args) throws InterruptedException {
		// Callback handler which can be implemented by consumers
		final BatchHandler batchHandler = new BatchHandler() {
			public void onAvailable(final ValueEntry entry) throws Exception {
				// process a new entry as it becomes available.
				entry.setCube((entry.value) * (entry.value) * (entry.value));
				StackTraceElement trace = Thread.currentThread().getStackTrace()[3];
				entry.setClassName(trace.getClassName());
			}

			public void onEndOfBatch() throws Exception {
				// useful for flushing results to an IO device if necessary.
			}
		};

		final BatchHandler batchLoger = new BatchHandler() {
			public void onAvailable(final ValueEntry entry) throws Exception {
				// process a new entry as it becomes available.
				System.out.println("Processing entry : " + entry.getValue());
				System.out.println("Cube : " + entry.getCube());
				System.out.println("Processed by : " + entry.getClassName().toString());

			}

			public void onEndOfBatch() throws Exception {
				// useful for flushing results to an IO device if necessary.
			}
		};

		ConsumerBarrier consumerBarrier1 = ringBuffer.createConsumerBarrier();

		// batch consumers are tied to consumerBarrier1
		BatchConsumerEven batchConsumerEven =
                                  new BatchConsumerEven(consumerBarrier1, batchHandler);
		BatchConsumerOdd batchConsumerOdd =
                                  new BatchConsumerOdd(consumerBarrier1, batchHandler);

		// consumerBarrier2 is tied to consumers batchConsumerEven and
		// batchConsumerOdd
		ConsumerBarrier consumerBarrier2 = ringBuffer.createConsumerBarrier(batchConsumerEven,
                                 batchConsumerOdd);

		// log consumer is tied to consumerBarrier2
		BatchConsumer logConsumer = new BatchConsumer(consumerBarrier2, batchLoger);

		// Each consumer can run on a separate thread
		EXECUTOR.execute(batchConsumerEven);
		EXECUTOR.execute(batchConsumerOdd);
		EXECUTOR.execute(logConsumer);

		// Producer code
		ProducerBarrier producerBarrier = ringBuffer.createProducerBarrier(logConsumer);

		for (long i = 0; i < = 1001; i++) {
			// Producer claims entries in sequence
			ValueEntry entry = producerBarrier.nextEntry();

			// copy data into the entry container
			entry.setValue(i);

			// make the entry available to consumers
			producerBarrier.commit(entry);
		}

		// Give 1 sec to end before exit
		Thread.sleep(1000);
		System.exit(0);
	}

	public final static class ValueEntry extends AbstractEntry {
		private long value;
		private long cubic;
		private String className;

		public long getCube() {
			return cubic;
		}
		public void setCube(long cube) {
			this.cubic = cube;
		}

		public long getValue() {
			return value;
		}
		public void setValue(final long value) {
			this.value = value;
		}

		public void setClassName(String className) {
			this.className = className;
		}
		public String getClassName() {
			return className;
		}

		public final static EntryFactory ENTRY_FACTORY = new EntryFactory() {
			public ValueEntry create() {
				return new ValueEntry();
			}
		};
	}
}

A noter la taille du Ring Buffer, alors que l’on envisage de traiter 1000 données, on ne déclare qu’une taille de 100.

C’est pour illustrer le principe de recyclage des entrées du Ring Buffer.

De plus la taille est obligatoirement de type 2ⁿ (soit 128 dans notre cas).

Affichage en sortie (Extrait)

Processing entry : 0
Cube : 0
Processed by : disruptor.BatchConsumerEven

Processing entry : 1
Cube : 1
Processed by : disruptor.BatchConsumerOdd

Processing entry : 2
Cube : 8
Processed by : disruptor.BatchConsumerEven

Processing entry : 3
Cube : 27
Processed by : disruptor.BatchConsumerOdd

Processing entry : 4
Cube : 64
Processed by : disruptor.BatchConsumerEven

Processing entry : 5
Cube : 125
Processed by : disruptor.BatchConsumerOdd

Processing entry : 6
Cube : 216
Processed by : disruptor.BatchConsumerEven

Processing entry : 7
Cube : 343
Processed by : disruptor.BatchConsumerOdd

Je ne suis pas un expert en judo et je ne me permettrai pas de commenter le sportif. Par contre j’ai vu aujourd’hui sur le tatami de . . . → Lire la suite: Judo – Bravo Fred]]> Notre collègue Frédérique Jossinet a terminé au pied du podium aujourd’hui aux Championnats du Monde, éliminée en quart de finale par la japonaise Fukumi qui finira médaille d’argent.

Je ne suis pas un expert en judo et je ne me permettrai pas de commenter le sportif. Par contre j’ai vu aujourd’hui sur le tatami de Bercy une athlète affutée qui dégageait un réel plaisir dans le combat et une énorme détermination.

Le chemin vers Londres 2012 continue pour Fred et toute l’équipe Ippon Technologies est avec toi pour tes prochaines échéances,

Retrouvez le communiqué de presse sur l’arrivée de Frédérique dans nos équipes : http://www.ippon.fr/web/guest/actu/communiques

Retrouvez les réactions de Frédérique sur l’Equipe.fr : http://www.lequipe.fr/Judo/breves2011/20110823_183810_jossinet-c-est-le-jeu.html

A suivre,

Geoffray

A ce titre, Julien Dubois, directeur du pôle conseil d’Ippon Technologies, viendra réaliser une conférence sur Hibernate et le cloud computing le 20 Septembre.

Cette conférence sera l’occasion de partager . . . → Lire la suite: Ippon au Bordeaux JUG]]> Ippon Technologies a ouvert cette année son agence de Bordeaux, et c’est donc tout naturellement que nous allons participer au JUG local, le Bordeaux JUG.

A ce titre, Julien Dubois, directeur du pôle conseil d’Ippon Technologies, viendra réaliser une conférence sur Hibernate et le cloud computing le 20 Septembre.

Cette conférence sera l’occasion de partager ensemble sur les nouvelles tendances de notre métier: le NoSQL, les systèmes de cache distribué… mais aussi de faire le point sur des technologies plus classiques, comme Hibernate ou les bases de données “traditionnelles”, et de voir quelles sont les problématiques (et solutions!) couramment rencontrées.

Rendez-vous sur le site du Bordeaux JUG pour plus de détails ainsi que pour vous inscrire: http://bordeauxjug.org/20110920_HibernateVsCloudComputing

Malgré ce planning ultra chargé, Fred a créé la surprise lors de la soirée d’inauguration des nouveaux locaux d’Ippon. D’abord par sa présence qui a ravie tous les Ipponniens (normal!) et par l’annonce . . . → Lire la suite: Quand Ippon rencontre Fred Jossinet… (Gagnez des places aux championnats du monde de Judo!)]]> Championnats d’Europe d’Istanbul, Grand Chelem à Rio, Stages d’entraînements Commando, Fred Jossinet enchaîne compétitions et entraînements en vue des Jeux Olympiques 2012.

Malgré ce planning ultra chargé, Fred a créé la surprise lors de la soirée d’inauguration des nouveaux locaux d’Ippon. D’abord par sa présence qui a ravie tous les Ipponniens (normal!) et par l’annonce de Stéphane Nomis ensuite:
“Frédérique Jossinet, médaillée aux JO de 2004, quatre fois médaillée aux Championnats du Monde, rejoint l’équipe Ippon Technologies”

Ce partenariat avec la Fédération Française de Judo permet à la grande judokate française d’intégrer l’entreprise tout en préparant les Jeux Olympiques 2012. Diplômée de l’ESSEC, lorsque Fred ne sera pas sur le tatami, elle mènera des actions de fonds sur des projets commerciaux et marketing pour le compte de la Direction Commerciale d’IPPON Technologies. Nous avons signé officiellement le contrat avec la FFDJ devant les médias le 26 juillet à Bourges lors des entraînements de préparation aux JO.

Nous souhaitons donc chaleureusement la bienvenue à Fred! Et en fervents supporters, nous soutiendrons avec enthousiasme notre grande star lors des prochaines compétitions, rediffusées en direct chez Ippon Technologies.

Et puisque nous parlons des prochaines compétitions….

Le prochain grand évènement du Judo, ce sont les Mondes qui se dérouleront à Paris du 23 au 28 août 2011. Pour l’occasion Ippon Technologies a réservé une loge pour toute la durée des compétitions et vous offre la possibilité d’aller soutenir Fred et nos athlètes français.

Le nombre de places est limité et mis en jeu ici

Il vous suffit de trouver les bonnes réponses au quizz pour vous inscrire au jeu et un tirage au sort désignera les gagnants! A vous de jouer et bonne chance! Les grands gagnants seront annoncés le 17 août.

Soit un site web exposé en HTTPS disons sur le nom de domaine mon.domaine.fr avec un certificat tout beau et tout . . . → Lire la suite: Pourquoi Firefox ou Java ne reconnaissent pas ce certificat SSL si chèrement payé ?]]> Je suis récemment retombé sur un problème avec un certificat SSL que je n’avais pas eut le temps d’analyser assez profondemment la première fois mais dont l’explication parait pourtant évidente après coup …

Le Problème

Soit un site web exposé en HTTPS disons sur le nom de domaine mon.domaine.fr avec un certificat tout beau et tout neuf fraichement signé par une autorité de certification plus que reconnue (VeriSign dans mon cas).

Et pourtant lorsque je m’y connecte avec mon application Java, la JVM m’insulte à coup de : javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
L’utilisation de la toute dernière version de la JVM n’y change rien.

Idem côté Firefox : l’accès avec un FireFox 5.0 (donc très récent) fraichement installé génère le warning suivant :

This Connection is Untrusted (…)
mon.domaine.fr uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

(Bon d’accord, avec cette version de FireFox, le message d’erreur est pourtant plus que significatif si on prend le temps de le comprendre…)

Si on ajoute un exception de sécurité à Firefox, la communication HTTPS fonctionne correctement. Le serveur semble donc être bien configuré pour gérer le SSL …

Pourtant le certificat exposé est bien signé par VeriSign. En particulier, le champ issuer/émetteur du certificat contient :

CN = VeriSign Class 3 International Server CA - G3
OU = Terms of use at https://www.verisign.com/rpa (c)10
OU = VeriSign Trust Network
O = "VeriSign, Inc."
C = US

Alors quoi ? Les certificats fraichement signés par une autorité reconnue ne fonctionnent pas par défaut ni avec Firefox ni avec Java ? Ca serait inquiétant non ? Surtout vu le prix qu’ils coûtent…

Heureusement il n’en est rien, ces certificats sont bien valides et toutes les versions de Firefox et toutes les versions de Java doivent pouvoir fonctionner avec sans avoir à les configurer au préalable.

Le problème ici est du côté du serveur…

Un peu de background sur les certificats

Un certificat est un document électronique qui contient en autre :

• une identité (dans notre cas l’identité d’un serveur via son nom DNS)
• une clef publique (associée à une clef privée détenue uniquement par le possesseur du certificat )
• l’identité de l’émetteur du certificat (l’autorité de certification ayant signé le certificat)
• une signature électronique garantissant l’intégrité du certificat ainsi que le fait que l’autorité de certification reconnait la véracité des informations du certificat.

La signature peut-être vérifiée à l’aide de la clef publique de l’émetteur.
Cette clef publique est mis à disposition à l’aide d’un certificat propre à l’émetteur. Celui-ci est aussi signé électroniquement éventuellement par une troisième autorité de certification. Et ainsi de suite …

On obtient alors une chaine de certification :
certificat A est signé par B, dont le certificat B est signé par C, etc …

Au bout de la chaîne, on trouve le certificat d’une autorité de certification racine qui est auto-signé (c’est à dire signée avec la clef privée associée à sa propre clef publique)

Il suffit normalement que votre navigateur ou votre application fasse confiance à l’un des certificats de la chaîne pour que le premier certificat soit lui aussi reconnu comme digne de confiance et que la communication SSL puisse s’établir sans erreur ou warning.

Les certificats émis par VeriSign ne sont pas directement signés par leur certificat racine. Ils sont signés par un certificat intermédiaire. (A noter : VeriSign utilise plusieurs certificats racine et plusieurs certificats intermédiaires suivant le niveau de sécurité et les autres options demandées …)

Dans notre cas, on a :

• le certificat de notre domaine mon.domaine.fr signé par “VeriSign Class 3 International Server CA – G3″
• le certificat intermédiaire ”VeriSign Class 3 International Server CA – G3″ signé par “VeriSign Class 3 Public Primary Certification Authority – G5″
• le certificat racine “VeriSign Class 3 Public Primary Certification Authority – G5″

Avec à la fois Java et Firefox qui font confiance par défaut au certificat racine “VeriSign Class 3 Public Primary Certification Authority – G5″ …

( Note : pour la jvm, vous pouvez connaître la liste des autorités de confiance par défaut via cette commande : keytool -list -v -keystore %JDK_HOME%\jre\lib\security\cacerts -storepass changeit )

L’explication

Normalement, on a donc tout bon :

• le serveur nous expose un certificat valide faisant partie d’une chaine de confiance
• nous faisons confiance à la racine de cette chaine

Pourquoi cela ne fonctionne-t-il pas ??

Le problème ici c’est que le serveur ne nous exposait QUE le certificat de mon.domaine.fr …

Il est donc impossible pour la jvm ou pour Firefox de savoir que l’émetteur : “VeriSign Class 3 International Server CA – G3″ a quelque part un certificat signé par “VeriSign Class 3 Public Primary Certification Authority – G5″ (auquel ils font confiance)

Pour que cela fonctionne, il faut que le serveur envoie non seulement le certificat de mon.domaine.fr mais aussi le certificat intermédiaire associé à “VeriSign Class 3 International Server CA – G3″ …

Une fois que l’on sait où chercher, la confirmation du diagnostique est simple :

• pour une application cliente java, on peut activer les debug ssl via l’option “-Djavax.net.debug=ssl”
  La chaîne de certificats exposés par le serveur sera alors tracée sur la sortie standard après une ligne “*** Certificate chain” (et juste avant que la jvm vous insulte car elle ne fait pas confiance au certificat )
  Si il y a qu’un seul certificat, on a bien le problème de configuration évoqué ici.
  Avec un serveur web correctement configuré, la chaîne contiendra normalement plusieurs certificats.
• on peut aussi utiliser cette commande de openssl si il est disponible sur votre système :
  openssl s_client -showcerts -connect mon.domaine.fr:443
  Elle affichera en particulier l’ensemble des certificats qui sont envoyés par le serveur.

Les solutions

Vous ne pouvez pas modifier le serveur https

Sans avoir la main sur le serveur web mal configuré, pas d’autre choix que de faire avec…

Il faut récupérer le certificat intermédiaire (sur le site de VeriSign) et l’ajouter aux certificats de confiance de votre navigateur et/ou de votre application java cliente.

Vous noterez que seul le certificat intermédiaire, celui ayant signé le certificat du serveur, est nécessaire. C’est généralement une mauvaise idée de mettre directement le certificat du serveur car lorsqu’il expirera il faudra obligatoirement le mettre à jour avec son remplaçant. Alors qu’il y a des chances que son remplaçant soit signé par le même certificat intermédiaire et alors tout continuera à fonctionner sans modification.

Dans une application java cliente, si vous avez une bonne raison, vous pouvez aussi bypasser complètement les contrôles de la JVM comme l’a expliqué Pierre-Alain ici : http://blog.ippon.fr/2008/10/20/certificats-auto-signe-et-communication-ssl-en-java/

Vous pouvez corriger la configuration du serveur https

Si vous pouvez modifier ou faire modifier le serveur Web posant problème, c’est évidemment la meilleure solution.

Cette page web : http://www.ssl247.fr/support/install/, explique comment configurer correctement de nombreux serveurs ou load-balancer avec en particulier la façon d’installer le certificat intermédiaire pour qu’il soit exposé au client avec le certificat du serveur.

Une bonne nouvelle pour nous qui faisons du Java :
si vous avez généré votre Certificat Signing Request (CSR) à l’aide de keytool (ou un outil encapsulant ces fonctionnalités), il ne vous permettra pas d’importer la réponse avec le certificat signé, si le keystore utilisé ne contient pas déjà l’ensemble de la chaîne de certification. La chaine de certification est donc obligatoirement disponible dans le keystore.

Après cela dépend de votre serveur d’application.
Pour Tomcat par exemple (voir aussi configuration des connecteurs tomcat) :

• avec l’implémention Java du connecteur https, Tomcat expose directement l’ensemble de la chaîne présente dans le keystore
• par contre avec l’implémentation APR du connecteur https, il est possible de mal le configurer, exactement comme pour le module mod_ssl de Apache httpd : dans les deux cas, l’option SSLCertificateChainFile est celle qu’il ne faut pas oublier de configurer.

L’équipe n°10 (Florent Ramière/Jaxio, Nicolas Romanetti/Jaxio, Bernard Pons/Banque de France, Julien Dubois/Ippon Technologies) a terminé 2ème, à un cheveu de l’équipe gagnante (équipe n°6, composée de membres de Xebia). Les . . . → Lire la suite: Comment gagner au Challenge USI 2011?]]> Déjà évoqué dans ce précédent billet, le Challenge USI 2011 s’est terminé la semaine dernière lors de l’Université du SI, événement sponsorisé par Octo Technologies.

L’équipe n°10 (Florent Ramière/Jaxio, Nicolas Romanetti/Jaxio, Bernard Pons/Banque de France, Julien Dubois/Ippon Technologies) a terminé 2ème, à un cheveu de l’équipe gagnante (équipe n°6, composée de membres de Xebia). Les technologies utilisées par ces deux équipes sont relativement proches, à la différence près du système de back-end:

• Gemfire: une solution de cache distribué qui est un produit commercial vendu par la société VMWare, pour l’équipe n°6,
• Cassandra: une base de données NoSQL distribuée, qui est une solution Open Source de la fondation Apache, pour l’équipe n°10

Nous vous proposons ici de détailler plusieurs des choix qui ont clairement fait la différence.

En effet:

• Les deux premières équipes ont tenu respectivement 200 000 et 210 000 connections simultanées
• La 3ème équipe a tenu 40 000 connections
• Les autres équipes n’ont pas pu dépasser les 12 000 connections

Tout d’abord, la première chose qui a fait la différence n’est pas technique, mais humaine: il est clair que ces deux équipes ont passé énormément de temps sur le challenge, sans doute beaucoup plus que la plupart des autres équipes.

Ensuite, passons à la technique: les deux premières équipes ayant réalisé leur application en Java, en utilisant Netty, on peut en conclure un certain nombre de faits:

• Java est très bien adapté pour de la haute volumétrie. En l’occurrence, les solutions Java ont ici battu des solutions codées en C, node.js, akka.io… Non seulement le monde a changé (Java tient la charge sur de la haute volumétrie, et peut se battre avec des applications en C), mais les nouvelles solutions à la mode (Node.js et akka.io) ont encore du chemin à faire.
• Plus spécifiquement, ce sont des solutions Java fortement optimisées qui ont gagné. Par exemple, certains compétiteurs ont utilisé Tomcat. C’est un grand classique de l’informatique: une solution spécialisée est toujours plus performante qu’une solution généraliste. Il ne faut donc pas en conclure que les serveurs d’application Java EE ne sont pas prêts pour ce niveau de charge: ils sont juste moins adaptés qu’un programme spécialisé, d’autant plus que les contraintes du challenge étaient très particulières au niveau HTTP (en particulier le fait de bloquer des requêtes HTTP, ce qui était une simplification de ce que l’on appelle habituellement du “long polling”).
• Le back-end posant problème, les solutions les plus performantes sont celles qui ont le plus minimisé les accès à ce back-end. Pour les deux solutions gagnantes, les écritures sont toutes asynchrones, afin de ne jamais bloquer de thread utilisée par Netty. D’autre part, les lectures sont réduites grâce à de nombreuses astuces: utilisation d’un hash pour éviter de devoir relire le login/mot de passe de l’utilisateur à chaque requête, le stockage de certaines données du jeu dans un cookie de manière à éviter à avoir à les relire en base… Par contre l’équipe n°6 utilisait un état stocké dans une session HTTP distribuée avec Gemfire, tandis que l’équipe n°10 avait une architecture “stateless” avec des données de session stockées dans un cookie.
• Une bonne utilisation de l’infrastructure est également primordiale: le tuning de l’OS et de la JVM font une différence énorme. Ubuntu, en standard, ne peut pas supporter ce type de charge, c’est pourquoi sa configuration a du être largement modifiée. Mais il y avait également un avantage à l’équipe qui connaissait bien les faiblesses de l’infrastructure virtualisée fournie: en effet, la configuration VMWare n’allouait que 2 gigas de RAM, pouvant monter à 4 en cas de charge. Il est donc probable que l’équipe n°6, qui a limité sa JVM à 2 Giga, a eu là un avantage: l’utilisation de l’ensemble de la RAM “virtuelle” par l’équipe n°10 ayant probablement fait s’écrouler les machines physiques hôtes. Enfin, l’équipe n°10 a fait l’erreur de sacrifier une machine pour faire des IP virtuelles avec LVS, alors que l’équipe n°6 a mieux géré ses ressources en répartissant cette configuration sur toutes leurs machines: étant donné que le test final n’était que sur 10 machines, cela leur a donc donné un net avantage en termes de puissance de calcul.

Malheureusement la plateforme de test n’a permis que de faire un test avec 10 machines virtuelles en parallèle, et nous ne pouvons donc pas savoir si l’une de ces architectures pouvait effectivement tenir le million d’utilisateurs simultanés, sur 100 machines distribuées, ce qui était l’objectif fiinal du jeu. On voit en effet ici que les contraintes de RAM et de nombre de machines disponibles ont eu un impact important sur les tests réalisés. L’un des effets principaux de la virtualisation a été de cacher aux compétiteurs les CPUs et la RAM rééllement disponibles, ainsi que la configuration réseau exacte, ce qui a eu un effet très négatif sur le tuning, et donc sur les performances finales.

L’équipe n°10 est en train de nettoyer son code avant de le mettre à disposition de tous sur GitHub: nous ne manquerons pas de vous tenir informés sur ce blog et via Twitter.

Vous trouverez plus d’informations sur le site du challenge.

JMS est une spécification très utilisée en entreprise, mais son API est relativement ancienne, ce qui est vite frustrant lorsqu’on l’utilise. C’est d’ailleurs l’une des raisons du succès de Spring JMS. Heureusement, l’expert group JSR . . . → Lire la suite: Qu’attendez-vous de JMS 2.0?]]> Ce post est écrit par Julien Dubois, membre de l’expert group JMS 2.0, et directeur du pôle conseil d’Ippon Technologies.

JMS est une spécification très utilisée en entreprise, mais son API est relativement ancienne, ce qui est vite frustrant lorsqu’on l’utilise. C’est d’ailleurs l’une des raisons du succès de Spring JMS. Heureusement, l’expert group JSR 343 (“JMS 2.0″) vient d’être formé afin de mettre à jour la spécification:

http://java.net/projects/jms-spec/pages/Home

Ce type de spécification a tendance à durer de nombreuses années: JMS 1.1 date de 2002, cela va donc bientôt faire une dizaine d’années! D’où l’importance de participer à son élaboration.

En tant que membre de l’expert group qui met en place cette spécification, je vous propose donc de participer sur ce blog, en Français, et de nous dire ce que vous voulez voir apparaître (et disparaître!) de la spécification JMS.

Voici ma proposition actuelle:

1. Configuration de JMS
   • l’API JMS ne devrait pas dépendre de JNDI, afin qu’elle soit utilisable en dehors d’un serveur d’application complet (on pourrait alors l’utiliser sans problème dans Tomcat, un batch, ou un ESB léger).
   • Le pooling des ressources JMS devrait être inclus dans cette configuration
   • Il y a aujourd’hui un débat sur la configuration dans JEE 7, lancé par Antonio Goncalves, et JMS 2.0 devrait y participer.
2. Simplification de l’API JMS
   • Certaines parties de l’API JMS ne sont pas claires, par exemple sur ce qui concerne l’acknowledgement des messages. Nous devrions juste avoir ”auto”, “client”, “dups-ok” et “transacted”, comme ce qui est proposé dans Spring JMS.
   • Il devrait y avoir une API plus simple pour envoyer et recevoir des messages, comme fourni par le JMSTemplate de Spring. Des librairies utilitaires et des wrappers ne devraient pas être nécessaires pour des cas d’utilisation simples.
3. Les annotations
   • Comme toute spécification moderne, il faut pouvoir utiliser les annotations pour la configuration.
4. Des MDB partout
   • Les Message-Driven Beans ne devraient pas être réservés aux seuls serveurs d’application. Nous devrions avoir des “message-driven POJOs” tels que fournis par Spring JMS, en utilisant des annotations sur un objet Java simple.
5. Le clustering et le failover
   • Le thème de JEE 7 étant “le cloud”, il devrait y avoir des options de configuration du clustering et du failover dans la spécification. Par exemple, il faudrait pouvoir configurer le failover comme proposé par ActiveMQ dans sa documentation. Il faudrait également avoir un système de callback pour gérer les cas d’erreurs.
6. Les batchs
   • Il faudrait pouvoir envoyer les messages par batch et non un par un.

Une autre proposition, qui revient régulièrement mais que nous n’avons pas repris, est celle de pouvoir envoyer des messages avec une date définie de réception. Par exemple, un producteur de message pourrait envoyer tous ses messages dans la journée, en disant qu’ils ne devront être délivrés que à minuit au destinataire.

Ippon sera bien entendu . . . → Lire la suite: Ippon au Jug Summer Camp]]> Le Jug Summer Camp, c’est LA conférence Java de la rentrée, qui aura lieu à La Rochelle le 16 Septembre 2011. La première édition avait été exceptionnelle: des conférences de très haut niveau, une excellente ambiance (la conférence a lieu sur le port de La Rochelle…), et une organisation sans faille!

Ippon sera bien entendu présent à cette conférence, avec la conférence “Hibernate vs. le Cloud Computing” animée par Julien Dubois.

Les inscriptions sont ouvertes depuis ce matin, dépêchez-vous de vous inscrire car les places pour ce type de conférence partent très vite en ce moment (comme l’a montré le BreizhCamp, où nous serons également présents). Pour les Parisiens, n’oubliez pas que La Rochelle est à moins de 3 heures de TGV de la capitale, et qu’il vaut mieux arriver la veille car il y aura très certainement un restaurant sur le port le soir.

Le premier Liferay Symposium aura lieu à Paris le mercredi 15 juin.

Le programme s’annonce riche et les speakers de qualité.

La DGA présentera avec Ippon Technologies à cette occasion la nouvelle version du projet Espace Partenaires qui est en production sur Liferay depuis maintenant plus de 5 ans et qui vient de migrer . . . → Lire la suite: Témoignage DGA au Liferay Symposium le 15/06 à Paris]]>

Le premier Liferay Symposium aura lieu à Paris le mercredi 15 juin.

Le programme s’annonce riche et les speakers de qualité.

La DGA présentera avec Ippon Technologies à cette occasion la nouvelle version du projet Espace Partenaires qui est en production sur Liferay depuis maintenant plus de 5 ans et qui vient de migrer sur la version Enterprise Edition de Liferay.

L’Espace Partenaires est un système d’information, mis en place par la DGA, qui donne aux acteurs du secteur de la Défense la possibilité de travailler en collaboration via un réseau sécurisé et privé.

La session vous proposera 5 ans de retour d’expérience sur Liferay avec un focus particulier sur les problématiques de gestion des communautés, de sécurité et de migration.

Les inscriptions au Symposium sont ouvertes sur le site de Liferay