Blog de David MASCLET

Deviner la variable JAVA_HOME en bash

Masclet — Fri, 16 Sep 2011 16:41:00 +0200

Lors de l'écriture de l'un de mes scripts, j'ai du deviner la variable JAVA_HOME. j'ai donc écrit une fonction en bash que je vous livre et qui pourra sans doute vous aider

#!/bin/bash
function guess_java_home(){
        for i in  `readlink -f \` which java\`` 
do 
        JAVA_HOME=${i/bin\/java/}
        echo "JAVA_HOME=${JAVA_HOME}"
done
}

EasyMock en environnement multithread

Masclet — Sun, 28 Nov 2010 13:39:00 +0100

Lorsque vous voulez 'mocker' un objet et que ce dernier sera appelé par plusieurs threads, vous aurez le message suivant "Un-thread-safe mock called from multiple threads".

Par exemple :

@test
public void MyTest(){
    List mockList = EasyMock.createMock(List.class);
    EasyMock.expect(mockList.add(EasyMock.anyObject())).times(NUMBER_OF_THREAD);
    EasyMock.replay(mockList);
                
    MyThread[] rateThread= new MyThread[NUMBER_OF_THREAD];
    for(int i=0;i<NUMBER_OF_THREAD;i++){
        rateThread[i]= new MyThread(){
           @Override     
               doit(){
                   mockList.add("foo");
               }
       };
     rateThread[i].start();
            
    }
}

Il vous faut alors ajouter EasyMock.makeThreadSafe(mockList, true);. avant le replay(mockList)

Les génériques java et EasyMock

Masclet — Thu, 21 Oct 2010 21:42:00 +0200

Parfois nous devons exécuter un traitement et si le résultat est null nous voulons renvoyer un résultat par défaut. par exemple une liste vide. cela permet d'éviter les NullPointerExceptions si nous parcourons la liste. Exemple :

List<Contact> contacts = getContacts();
for (Contact contact : contacts){
      contact.setActive(true);
}

Si getContacts() renvoie null le code renverra une NullPointerException. il est possible avec les génériques Java de le faire d'une manière élégante :

 public static <T> T notNull(T test, T defaultvalue){
    return t == null ? test : defaultValue;
  }

On peut alors écrire :

List<Contact> contacts = notNull(getContacts(),new ArrayList<Contact>);

Ce code n'est pas révolutionnaire mais il montre à quel point les génériques de de Java peuvent être utiles. C'est d'ailleurs de cette manière que EasyMock fonctionne. Lorsque vous écrivez

Myclass mock = EasyMock.createMock(MyClass.class);
EasyMock.expect(mock.function()).andReturn(value);

Le type de value est déterminé en générique Java par le retour de function() :

 public <O> O expect(O t) {
        return t;
    }

Hibernate : différence entre get() et load()

Masclet — Wed, 13 Oct 2010 14:12:00 +0200

Si vous êtes un utilisateur d'Hibernate, que ce soit avec Spring ou pas, vous êtes vous déjà posé la question de savoir quelles sont les différences entre session.load() et session.get(). Comprendre les différences permet souvent d'optimiser les accès à la base de données.

En effet les signatures des deux méthodes sont assez proches et permettent toutes les deux de récupérer une entité via sa clé. Voici donc les différences :

get() renvoie null si l'objet n'existe pas, tandis que load() lève une objectNotFoundException. Ce qui veux dire que le fait que l'objet n'existe pas est considérer comme une erreur applicative. Il faut donc utiliser load() si tel est le cas. Par contre la javadoc est claire : You should not use this method to determine if an instance exists (use get() instead). en résumé n'en faites pas une utilisation détournée ;)

La deuxième différence est structurelle. Lorsque vous faites un get(), vous récupérez l'objet avec ses champs chargés (en fonction des attributs lazy, cela va sans dire). En revanche lorsque vous faites un load, Hibernate vous renvoie un proxy que sera initialisé lors de l'appel à un champs ou a un getter. Si la session est fermé, vous aurez alors une LazyInitializationException :

session.beginTransaction();

User user=(User) session.load(User.class, new Long(1));

session.getTransaction().commit();

user.getPassword();//=>LazyInitializationException

Vous n'auriez pas eu cette exception si vous auriez utilisé get()

La question qui vient alors à l'esprit est "si on ne doit pas utiliser load() pour tester l'existence d'un objet, et que les champs ne sont pas initialisés, quand utilisez load()?"

En fait, la réponse découle du modèle relationnel du SQL : lorsque vous avez une association OneToMany cela se traduit pas une relation de clé primaire / étrangère. Chose qui n'existe pas dans le modèle Objet (d'où l'intérêt d'Hibernate ;) ). pour associer un objet en SQL il suffit uniquement de connaitre la clé primaire de l'objet associé. et c'est là qu'intervient l'utilité de load(). Nous n'avons besoin que de sa clé, pas des champs. voici un exemple de code :

Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();

User owner = session.get( User.class, 1 );//un appel
Car  car = session.get( Car.class, 2 );//deux appel
owner.setCar(car);//un save

tx.commit();
session.close();

Cela fait deux appels à la database + un save (pas de cache dans notre exemple). En revanche :


Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();

User owner = session.load( User.class, 1 );
Car  car = session.get( Car.class, 2 );//un appel
owner.setCar(car);//un update

tx.commit();
session.close();

Nous avons économisé un appel à la base.

à vos refactoring :)

Gérer les sessions Hibernate sans transaction

Masclet — Wed, 06 Oct 2010 22:45:00 +0200

Comme vous le savez déjà peut être, les sessions Hibernate sont très fortement couplées aux transactions : Hibernate ouvre et ferme les sessions au début et à la fin d'une transaction. Lors du développement d'une librairie (DAO), Je me suis posé la question "est il possible de ne pas utiliser un contexte transactionnel pour gérer les sessions ?". En effet lors de mes tests qui sont transactionnels, tout se passait bien mais lorsque j'intégrais mon code dans un contexte non transactionnel et que je tentais de récupérer des associations liées à une entité, j'avais des lazyInitializationException car les sessions était fermées. j'avais alors plusieurs solutions :

Utiliser le filtre Spring Opensessioninviewfilter, mais cela rend ma librairie non portable car cela ne fonctionnera que dans un contexte web
Faire des méthodes ad'hoc pour récupérer l'entité ou l'entité avec ses associations chargées (eager), mais au détriment d'un code moins lisible et où il est facile de ne pas utiliser la bonne méthode
Charger les associations directement (par configuration) avec FetchType=Eager. pas assez performant !
Utiliser les profiles de fectching
Faire une gestion des session par thread.

Je vous propose de voir comment j'ai implémenté la dernière solution

Pour ne pas avoir à gérer mes sessions / transactions à la main, j'utilise Spring, c'est donc à ce dernier que revient la tâche de les ouvrir et de les fermer. Spring fournit plusieurs "facilities" pour gérer les DAOs, dont celui d'Hibernate : HibernateDaoSupport. Cette classe permet de "wrapper" les méthodes d'Hibernate pouvant faire du CRUD et de s'affranchir de la gestion des sessions. elle permet également de réalisé un traitement (callback) au sein d'une session via une template hibernate (hibernatTemplate). Spring ouvre alors une session, exécute le callback, puis il se chargera de fermé la session :

Soit à la fin de la transaction
Soit à la fin de la requête HTTP dans le cas de l'utilisation de Opensessioninviewfilter.

Le code d'un callback ressemble alors à cela :

public monDao extends HibernateDaoSupport

 public Collection loadProductsByCategory(String category) throws DataAccessException {
        return this.getHibernateTemplate().find(
            "from test.Product product where product.category=?", category);
    }

Le déroulement est donc le suivant : HibernateDaoSupport->getHibernatTemplate()->getSession()->Création / réutilisation d'une session selon paramétrage->exécution du callback-> fermeture de la session

il me suffit donc de redéfinir la méthode getsession() de HibernateCallback. Pour cela, il faut que je change l'appel à getHibernateTemplate(). Pas de chance! cette méthode est final (sick !). je vais devoir rusé. je vais donc remonter jusqu'au HibernateDaoSupport, et créé le mien : NotTransationnalHibernateDaoSupport.

Je reprends donc le code, puis redéfinis la méthode getHibernateTemplate(), qui me renverra non plus une HibernateTemplate mais une NonTransactionnalHibernateTemplate, qui elle même redéfinira getSession(), qui elle même s'appuiera sur une politique de gestion des sessions par Thread.

Pour la gestion par thread je me dis que partir du code de Opensessioninviewfilter est un bon départ, car elle permet déjà de faire une gestion des sessions particulière : il me faut ouvrir une session, l'affecter dans un ThreadLocal, et la fermer lorsque le Thread disparait

package org.springframework.orm.hibernate3.support;

import org.hibernate.FlushMode;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.dao.DataAccessResourceFailureException;
import org.springframework.orm.hibernate3.SessionFactoryUtils;
import org.springframework.orm.hibernate3.SessionHolder;
import org.springframework.transaction.support.TransactionSynchronizationManager;

public class OpenSessionInThread extends Thread {

    public static final String DEFAULT_SESSION_FACTORY_BEAN_NAME = "sessionFactory";

    private FlushMode flushMode = FlushMode.MANUAL;

    private SessionFactory sessionFactory;

    public OpenSessionInThread(SessionFactory sessionFactory) {
        super();
        this.sessionFactory = sessionFactory;
        Runtime.getRuntime().addShutdownHook(this);
    }

    public Session getSession() {
        Session session = null;
        if (TransactionSynchronizationManager.hasResource(sessionFactory)) {
            session = ((SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory)).getValidatedSession();
        } else {
            session = getSession(sessionFactory);
            TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(session));
        }

        return session;
    }

    protected Session getSession(SessionFactory sessionFactory) throws DataAccessResourceFailureException {
        Session session = SessionFactoryUtils.getSession(sessionFactory, true);
        FlushMode flushMode = this.flushMode;
        if (flushMode != null) {
            session.setFlushMode(flushMode);
        }
        return session;
    }

    protected void closeSession() {
        Session session;
        if (this.sessionFactory != null) {
            if (TransactionSynchronizationManager.hasResource(this.sessionFactory)) {
                session = ((SessionHolder) TransactionSynchronizationManager.getResource(this.sessionFactory)).getValidatedSession();
                SessionFactoryUtils.closeSession(session);
            } else {
                System.err.println("can not close session, session is not in thread");
            }
        } else {
            System.err.println("can not close the session because session factory is null");
        }

    }

    @Override
    public void run() {
        closeSession();

    }
}

Il faut maintenant que j'intègre cela dans la méthode getSession() de ma classe NotTransactionnalHibernateTemplate :

package org.springframework.orm.hibernate3;

import java.sql.SQLException;

import org.hibernate.FlushMode;
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.dao.DataAccessException;
import org.springframework.orm.hibernate3.support.OpenSessionInThread;
import org.springframework.util.Assert;

public class NotTransactionalHibernateTemplate extends HibernateTemplate {

    private OpenSessionInThread openSessionInThread;

    public NotTransactionalHibernateTemplate(SessionFactory sessionFactory, boolean allowCreate) {
        super(sessionFactory, allowCreate);
    }

    @Override
    public boolean isCheckWriteOperations() {
        return false;
    }

    /**
     * @param sessionFactory
     */
    public NotTransactionalHibernateTemplate(SessionFactory sessionFactory) {
        super(sessionFactory);
        openSessionInThread = new OpenSessionInThread(sessionFactory);
    }

    @Override
    public boolean isAllowCreate() {
        return false;
    }

    @Override
    public boolean isAlwaysUseNewSession() {
        return false;
    }

    @Override
    protected Session getSession() {
        Session session = openSessionInThread.getSession();
        session.setFlushMode(FlushMode.AUTO);
        return session;

    }

    @Override
    protected <T> T doExecute(HibernateCallback<T> action, boolean enforceNewSession, boolean enforceNativeSession) throws DataAccessException {

        Assert.notNull(action, "Callback object must not be null");
        Session session = (enforceNewSession ? SessionFactoryUtils.getNewSession(getSessionFactory(), getEntityInterceptor()) : getSession());
        boolean existingTransaction = (!enforceNewSession && (!isAllowCreate() || SessionFactoryUtils.isSessionTransactional(session, getSessionFactory())));
        if (existingTransaction) {
            logger.debug("Found thread-bound Session for HibernateTemplate");
        }

        try {
            Session sessionToExpose = (enforceNativeSession || isExposeNativeSession() ? session : createSessionProxy(session));
            T result = action.doInHibernate(sessionToExpose);
            session.flush();
            return result;
        } catch (HibernateException ex) {
            session.clear();
            throw convertHibernateAccessException(ex);
        } catch (SQLException ex) {
            session.clear();
            throw convertJdbcAccessException(ex);
        } catch (RuntimeException ex) {
            session.clear();
            throw ex;
        }
    }

}

Ca y est ! maintenant ma gestion des sessions est liée au cycle de vie du Thread.

Je redéfinis ensuite la méthode getHibernateTemplate() de ma classe NonTransationnalHibernateDaoSupport :

protected HibernateTemplate createHibernateTemplate(SessionFactory sessionFactory) {
                return new NotTransactionalHibernateTemplate(sessionFactory);
        }

maintenant je change l'héritage dans mes DAOs pour qu'il étendent NonTransationnalHibernateDaoSupport.

Il me reste cependant un dernier détail a gérer : il ne faut pas que la session soit fermée ailleur que dans ma classe de gestion de sessions, or en regardant où est utilisée getSession(), je me rend compte que dans la méthode doExecute(), la session peut être fermée dans certain cas. Je modifie donc le code. vous remarquerez que je fais un clear de la session si une exception est levée afin de ne pas exécuter d'autre traitement :

 @Override
    protected <T> T doExecute(HibernateCallback<T> action, boolean enforceNewSession, boolean enforceNativeSession) throws DataAccessException {

        Assert.notNull(action, "Callback object must not be null");
        Session session = (enforceNewSession ? SessionFactoryUtils.getNewSession(getSessionFactory(), getEntityInterceptor()) : getSession());
        boolean existingTransaction = (!enforceNewSession && (!isAllowCreate() || SessionFactoryUtils.isSessionTransactional(session, getSessionFactory())));
        if (existingTransaction) {
            logger.debug("Found thread-bound Session for HibernateTemplate");
        }

        try {
            Session sessionToExpose = (enforceNativeSession || isExposeNativeSession() ? session : createSessionProxy(session));
            T result = action.doInHibernate(sessionToExpose);
            session.flush();
            return result;
        } catch (HibernateException ex) {
            session.clear();
            throw convertHibernateAccessException(ex);
        } catch (SQLException ex) {
            session.clear();
            throw convertJdbcAccessException(ex);
        } catch (RuntimeException ex) {
            session.clear();
            throw ex;
        }
    }

Afin de testé si cela fonctionne, je désactive les transactions dans mes tests, et étendAbstractJUnit4SpringContextTests au lieu de AbstractTransactionalJUnit4SpringContextTests, je rajoute également une méthode pour effacer les enregistrements dans mes tables à la fin de chaque test :

// public abstract class AbstractDatabaseTestCase extends AbstractTransactionalJUnit4SpringContextTests{
public abstract class AbstractDatabaseTestCase extends AbstractJUnit4SpringContextTests{

@After
    public void cleanAll() {
        dao1.flushAndClear(); 
        dao1.deleteAll(dao1.getAll());
        
        dao2.flushAndClear(); 
        dao2.deleteAll(dao2.getAll());
....

    }

Reste à vérifier si cela fonctionne !

En l'absence de transaction, si mes DAO étendent NonTransationnalHibernateDaoSupport, les associations chargées en lazy ne font plus de lazyInitializationException alors que c'est le cas si mes DAOs étendent HibernateDaoSupport CQFD !

pour ceux qui sont intéressé, j'ai joint les sources à ce billet.

Autocomplétion dans l'interpréteur interactif Python

Masclet — Thu, 12 Aug 2010 09:47:00 +0200

Je vous propose une petite astuce pour activer l'autocomplétion ainsi qu'un historique des commandes tapées dans l'interpréteur Python. Python 2.0 minimum est requis

#!/usr/bin/env python
# Add auto-completion and a stored history file of commands to your Python
# interactive interpreter. Requires Python 2.0+, readline. Autocomplete is
# bound to the Esc key by default (you can change it - see readline docs).
#
# Store the file in ~/.pystartup, and set an environment variable to point
# to it, e.g. "export PYTHONSTARTUP=/max/home/itamar/.pystartup" in bash.
#
# Note that PYTHONSTARTUP does *not* expand "~", so you have to put in the
# full path to your home directory.

import rlcompleter
import readline
readline.parse_and_bind("tab: complete")
import os
histfile = os.path.join(os.environ["HOME"], ".pyhist")
try:
    readline.read_history_file(histfile)
except IOError:
    pass
import atexit
atexit.register(readline.write_history_file, histfile)
del histfile, readline, rlcompleter

Sauvegarder le code ci dessus dans un fichier : ~/.pystartup
Définissez une variable d'environnement pointant vers ce fichier dans le fichier bashrc : (~/.bashrc) :

export PYTHONSTARTUP=/home/user/.pystartup

David

Le cloud computing

Masclet — Thu, 10 Jun 2010 15:43:00 +0200

Le cloud computing est un concept ou les applications sont exécutées par une puissance de calcul dont on ne gère plus l'infrastructure sous-jacente, on parle alors de puissance de calcul ou de stockage à la demande. Par analogie on peut comparer le cloud computing à la consommation électrique : on fait varier la production en fonction de la demande.

Pourquoi

Tout d'abord pour permettre une sécurité de fonctionnement accrue, une scalabilité plus facile, une maitrise (un besoin ponctuel) et une diminution des couts (moins de main d 'oeuvre), une professionnalisation (moins de savoir faire nécessaire)

Pour quelles applications ?

Le cloud computing est très adapté pour les applications de services dites SaaS (Software as a service), car l'utilisation de ces services peuvent varier en charge dans le temps.

Exemples d'API

L'api la plus connue est sans doute l'api d'Amazon. Amazon qui au départ n'était qu'un site internet à fort trafic, a su mettre à profit leur expertise dans la scalabilité, et fournissent désormais des services de cloud computing. Amazon Elastic Compute Cloud plus connus sous le nom de EC2 génère plus de trafic que le site d'Amazon lui même et fait partit des nombreux service commercialisés sous le nom d'Amazon Web Services ou AWS. AWS propose entre autre un services de stockage à la demande appelé S3, de base de données (SimpleDB) ainsi que des services de micro paiement (FPS), d'authentification (Amazon AWS Authentication) et des services métiers sur la librairie en ligne d'Amazon. EC2 permet via une interface web de pouvoir créer, supprimer, démarrer et arrêter des serveurs dont la facturation se fait au temps d'utilisation. Bien qu'on ne gère pas les serveurs et l'aspect technique il est tout de même possible de créer des serveurs virtuels sur des instances de serveurs physiques différentes afin de permettre la tolérance aux pannes. Ceci évite les coupures de services si l'un des serveur physique tombe et que tous les serveurs virtuels étaient installés dessus.

Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems) est une solution open source disponible en standard sur les versions d'Ubuntu supérieure a 9.04. Eucalyptus est compatible avec Amazon Web Services. il s'installe aussi sur d'autre plateformes comme CentOS ou Debian.

Tout les 'grands' s'y sont mis :

Windows Azure et Azure Services pour Microsoft
Blue Cloud d'IBM
HP dispose une son offre New Generation Data Center (NGDC) pour virtualiser des machine HP-UX
projet Hydrazine de Sun
Google App Engine pour Google qui lui se base plus sur des API spécifiques en Java ou python plutôt que sur de la virtualisation pure.
Salesforce, lui, fournit des logiciels de gestion de relation client.

On assiste aussi à des rapprochement : IBM et Google ont signé un accord visant à mettre en commun leurs ressources de cloud computing. et Google vise à connecter ses applications bureautiques de Google aux environnements de Salesforce.

Pour ceux que ça intéresse, je vous conseille la lecture de cet article qui explique comment Ebay conçoit ses architectures pour permettre le passage à l'échelle : http://www.infoq.com/articles/ebay-scalability-best-practices

Autres liens :
http://blog.octo.com/deploiement-dune-application-sur-linfrastructure-amazon-13/

http://blog.octo.com/comment-segment-l-offre-de-cloud-computing/

10 minutes pour comprendre...NoSQL

Masclet — Wed, 09 Jun 2010 14:31:00 +0200

Lorsque l'on parle de sites à fort trafic et de bases de données, on n'entend rarement parler de bases de données relationnelles. En effet, garantir la consistance des données coute chère en temps et est souvent incompatible avec les performances.

Puisque le modèle relationnel ne semble pas adapté dans des environnement nécessitant de grosses architectures et que les propriétés ACID des bases ne permettent généralement pas de passer à l'échelle, un nouveau mouvement (encore un ;)) est née de l'initiative des architectes de cloud computing et des sites communautaire comme Facebook, Amazon et Linkin : le NoSQL, (aka : Not Only SQL). Ce billet tente de faire le tour d'horizon des différents types de bases NoSQL, les différentes solutions disponibles sur le marché et dans quels cas les utiliser.

Le partitionnement

Le point de contention des applications est bien souvent la base de données qui lorsqu'elles sont transactionnelles, distribuées, ne permettent pas facilement le passage à l'échelle. Que l'on fasse du lock optimiste, pessimiste ou transaction à deux phases, on couple toujours les données entre elles, ce qui empêche la sérialisation. En plus, pour la sécurité de fonctionnement, il faut que les données soient répliquées, se qui complique encore un peu plus les choses. Dans les architectures modernes, la validation du modèle se fait désormais dans les objets, au niveau de l'applicatif. Cela permet de soulager la base et de ne se concentrer que sur les requêtes. des mouvements comme le DDD ont remis au gout du jour les objets avec du code métier plutôt que des POJOs.

Lorsque l'on veux scaler une base de données,une première solution peut être le partitionnement :

Vertical : une base pour les livres, une base pour les CDs, etc
Horizontal : une base pour les livre de A-M et une pour les livres de N-Z, ...

C'est donc une segmentation intelligente qui permet une montée en charge. mais cette architecture montre tout de même des limites, c'est là que le NoSQL entre en jeu

Le théorème de CAP

La quasi totalité des sites à fort trafic n'utilisent pas de base de données relationnelles avec des propriétés ACID mais plutôt des bases de données dites NoSQL basées sur le théorème de CAP d’Eric Brewer, qui est plus adaptés aux données massivement partagés.

En voici les 3 principes :

Consistance (consistency /C) : Tous les clients voient la même vue même lorsqu’il y a des mises-à-jour, en fait il s'agit du 'Atomic' des propriétés ACID.
Haute disponibilité (availability /A) : L’ensemble des clients peuvent trouver des données répliquées, même lorsqu’une avarie survient
Tolérant à la partition (partition-tolerance /P) : Le système est tolérant au partitionnement.

En revanche, seul deux des trois principes peuvent être respectés en même temps, souvent ce sont les deux derniers principes qui sont choisis (c'est le cas d 'Amazon par exemple) car le besoin en disponibilité et en partitionnement est souvent plus important que la consistance.

Les utilisateurs n'ont pas forcément tous la même vue à un moment donné, mais est-ce vraiment une nécessité ? Dans certains cas oui mais souvent non. Si vous faites une recherche sur Google et que vous n'avez pas exactement la même réponse qu'un autre utilisateur cela parait moins important que de ne pas avoir de résultats de recherche du tout (pas de haute disponibilité) !

Souvent, si la consistance est importante pour certaines données, il est d'usage de les isoler dans des bases relationnelles et de placer les autres données dans des bases dite NoSQL.

Certaines données nous paraissent logiques d'être consistantes mais cela est souvent du à notre inertie d'esprit. Prenons le cas d'une valeur indiquant le stock d'un article. Si deux serveurs ont des valeurs non consistantes, il peut arriver qu'un serveur considère qu'il en reste un alors qu'un autre qui a était mis à jour, sait qu'il n'en reste plus. Lorsque vous faites un achat et si par malchance vous acheter un livre qui n'est plus en stock, le site marchand à deux possibilités : vous rembourser ou réapprovisionner le stock (je ne sais pas vous, mais cela m'est déjà arrivé de recevoir un mail en disant que le produit était épuisé,après l'avoir commandé)

Dans cet exemple, vous pouvez avoir des désagrément mais je pense qu'entre

acheter sur un site très lent (disons quelques dizaine de secondes de latence par page) mais où le stock est en tant réel entre les milliers de serveurs pour tous les produits du site
une éventualité de stock non cohérente mais une haute disponibilité,

les sites ont fait leur choix ! Amazon a d'ailleurs constaté qu'un dixième de seconde de latence leur fait diminuer les ventes de 1%, et Google a remarqué qu'une demi seconde de latence fait chuter le trafic d'un cinquième.

Le fait d'accepter des données inconsistantes est connu sous le nom de BASE (Basically Available, Soft-state, Eventually consistent) qui est en fait, l'opposé des propriétés ACID. Le fait d'accepter que deux des trois principes du théorème de CAP peuvent être satisfait en même temps a fait le succès des plus gros sites de la planète, alors si cela a marché pour eux, je ne vois pas pourquoi cela ne marcherai pas pour d'autres.

Les 4 types de bases NoSQL

il existe 4 catégories de base NoSQL.

Orientées colonnes, comme HBase, Hypertable ou Cassandra, elles sont basées sur le concept de BigTable de Google
Basées sur la théorie des graphes (Euler) implémenter par Neo4J.
Orientées clé-valeur (Voldemort, Dynomite, Riak).
Orientées document, comme CouchDB.

Voyons maintenant leurs spécificités plus en détail :

Bases de données orientés colonnes :

Alors que les colonnes sont statiques pour une base relationnelle, elles sont dynamiques pour une base de données orientée colonnes, il est alors possible d'ajouter des colonnes dynamiquement et il n'y a pas de coût de stockage pour les valeurs Null.

Pour des raisons de performances les colonnes sont triées sur le disques, minimisant les accès aléatoires. De plus pour Cassandra, les écritures sont séquentielles pour éviter les latences de disques durs, les données sont tout d'abord écrites en mémoire, puis, persistées sur le disque lors d'un commitlog ou lorsque la mémoire est pleine.

Les BDD orientées colonnes sont prévues pour stocker des millions de colonnes, ce qui en fait des bases adaptées au stockage one-to-many. L'inconvénient est bien sur la mise à jour. Alors que pour une base de donnée relationnelle, une mise à jour du tuples disposant d'une clé étrangère peux suffire, une BDD orientée colonnes peut nécessiter une mise à jour de toutes les valeurs d'une colonne pour tous les enregistrements.

Il existe également des super colonnes qui sont des conteneurs de colonnes.

Les requête sont assez minimalistes, par exemple :

Toutes les colonnes ayant comme clé 256
Les colonnes dont le nom est compris entre 'bbb' et 'bbc' et dont la clé est 8652
La colonne 'abc' pour les lignes allant de 500 à 1000.

Cassandra (initialement utilisé par Facebook pour les messages non instantanés) et HBase sont des solutions de BDD orientées colonnes. Cassandra permettait à Facebook d'accéder aux messages échangés entre utilisateurs et aux messages comportant certains mots.

Ces bases sont destinées à des usages où l'on doit stocker des données par utilisateur et des données uniques. Ne chercher pas à faire du relationnel avec cette base, la mailing liste est pleine de ce genre de questions mais ce n'est tout simplement pas fait pour !

Bases de données orientées graphes.

Les bases de données orientés graphes n'ont pas pour but premier de résoudre des problèmes de performances mais plutôt de palier à des problèmes impossibles à résoudre avec des BDD relationnelles.

Le cas d'utilisation typique est bien sur les réseaux sociaux où l'aspect graphe prend tout son sens, mais aussi où des relations complexes entre les acteurs ont besoin d'être décrits (pièces d'une machine, arbre généalogique). Les bases de données orientés graphes ne représenteront probablement pas la majeure partie des BDD NoSQL.

Neo4J semble être actuellement la solution la plus mature.

Base de données clé-valeur

Dynamo, développé par Amazon, semble la plus connue des BDD clé-valeur. En simplifiant à l'extrême, les bases de données clé-valeur sont de grosses tables de hashage, leur légitimité se trouve dans le fait que les entités sont, dans une grande partie des cas, rapatriées à partir d'un identifiant. Toutefois le fonctionnement de ces bases est loin d'être aussi simple : les tables sont partitionnées. La partition est choisie en fonction d'un hash de la clé, qui donnera l'instance qui se chargera du stockage. Tout réside donc dans l'algorithme de la fonction de hashage qui doit garantir une répartition la plus égale possible entre les partitions.

Les données, à la différence d'une table de hashage, sont redondées. Afin de ne pas être sur un modèle 1 partition = 1 partition répliquée = 1 machine, chaque machines se voit attribuer une ou plusieurs partitions offrant ainsi de meilleurs performances et une tolérance aux pannes accrue.

Une des particularité de ces bases est que l'on peux choisir le niveau de consistance. ce niveau est défini par un quorum correspondant aux nombres de réponses de la part des partitions pour lequel on considère les données consistante. Si l'on veux que les données soit 100 % consistantes (toutes lectures sur n'importe quelles partitions donneront le même résultat), on définit alors le quorum au maximum. Le quorum peux être différent en lecture et en écriture, par contre des conflits de versions peuvent apparaitre, c'est alors à l'application cliente de résoudre les conflits (quelle version garder? un peu comme quand vous résolvez les conflits avec SVN).

Bases de données orientées documents

Elles sont une évolution des bases de données clé-valeur, où à une clé, est associé un document dont la structure est libre. il faut cependant que la base soit consciente de ce qu'elle stocke afin de permettre des fonctionnalités sur les documents. Je trouve que ces bases ressemblent beaucoup, au niveau stockage, à des utilisations comme SOLR / Lucene, ou a Xylème de l'INRIA (j'ai fais mon mémoire d'ingénieur sur ce projet).

De part son modèle, ces BDD se pré destine au stockage d'informations one-to-one et one-to-many et au stockage d'informations de session, de données de fichiers, pages web, etc

Un mot sur la sérialisation des données

Lorsque les données sont dispersées, et que l'on doit faire des traitement dessus, il faux souvent les véhiculer. Les grands comptes optent souvent pour des solutions évitant les sérialisation à outrance, les données ne sont pas véhiculées sur le réseau, seul l'endroit où elle se trouvent l'est. La donnée doit être accédée le plus tardivement possible ce qui permet d'économiser du réseaux, de la mémoire et du CPU. De plus les traitements doivent être insensibles à l'ordre d'arrivée des messages : la synchronisation tue les systèmes distribués !

conclusion

Pour le moment, le NoSQL est un mouvement grandissant, bien qu'il soit utilisé par les grand comptes qui sont à l'origine du mouvement. il n'y a pas de solutions qui se démarque vraiment du lot, il n'y a que des solutions adaptés aux besoins. On remarquera aussi qu'il manque vraiment des standards, comme JDBC et SQL le sont pour les SGBDR, mais cela s'explique sans doute par la jeunesse du mouvement et l'hétérogénéité des type de bases.

Les différents modèles économiques de l'open source

Masclet — Wed, 19 May 2010 10:05:00 +0200

Souvent lorsque je parle de Gisgraphy, la question qui m'est posée est "quelles sont tes motivations" et "est-ce que tu gagnes de l'argent avec ce projet". Après leur avoir expliquer que le projet est open source et libre. La réaction est quasi toujours la même : "tu n'a pas peur que quelqu'un te pique le projet ? et comment peut on gagner de l'argent alors que tout est gratuit ?". J'ai donc décidé de faire ce billet pour expliquer mes motivations ainsi que les différentes façons de gagner de l'argent avec des projets open source et libres. autant vous le dire tout de suite : je perds de l'argent avec Gisgraphy, mais mon but n'est pas forcément d'en gagner (même si j'aimerais ne pas être de ma poche ;) )

Un peu de vocabulaire

J'avoue que dans ce billet je mélange un peu les termes : Open source, gratuit, libre. bien que différents, je vais parler d'une façon générale des différents moyens de gagner de l'argent quand on fait un logiciel libre et / ou open source.

Gagner de l'argent avec de l'open source

Le modèle de licence des logiciels propriétaires est appelé EULA (End User License Agreement) en anglais et traduit par CLUF (Contrat de Licence Utilisateur Final) en français. Le principe est très simple : Donne moi de l'argent en échange de mon logiciel. et maintenant débrouille toi avec ce que je t'ai vendu ! Microsoft, comme comme beaucoup d'éditeurs de logiciels propriétaires fonctionne de cette façon. Le principe est simple et le modèle économique évident : l'achat !

Lorsqu'on développe un logiciel open source, il faut se creuser un peu plus les méninges. Comment un logiciel gratuit et dont le code est disponible peut rapporter de l'argent ? pourtant ce modèle est déjà rependu dans notre quotidien, mais peut être ne vous en rendez vous plus compte :

Les journaux quotidiens gratuits (20 minutes, Direct soir, métro)
Google Maps
Firefox et Thunderbirds
Wikipédia

Les différents modèles

Voici quelques modèles utilisés pour gagner de l'argent avec de l'open source / libre :

Support Ware : Donnez nous de l'argent et nous répondrons à vos questions (au moins nous ferons de notre mieux). mail, téléphone, forums, peu importe. Red hat fonctionne sur ce principe.
Product Ware : Le logiciel est gratuit, vous achetez juste 'le matériel' dans lequel il tourne . Android, Google Apps & Search Appliance utilise ce principe (Google ne fournit pas l'hébergement)
Cloud Ware : Donne de l'argent pour ce que le logiciel. L'argent ira je ne sais où (dans les nuages ;) ), mais tu auras le bénéfice des retombées. SugarCRM est basé sur ce modèle.
Project Ware : Besoin de réaliser un projet ? nous pouvons le faire pour vous en open source ! Payez nous pour notre travail et pour le projet. IBM réalise des tonnes de projets sur ce modèle
SaaS Ware : Notre logiciel est un logiciel de service (SaaS : Software as a Service), vous pouvez le louer à l'heure, à la semaine, au mois,....Ce modèle est très populaire. Zoho comme beaucoup d'autre fonctionne sur ce modèle. Geonames, lui mise sur des données édités par tous et fournit des services gratuits et payant par dessus.
Ad Ware : Vous ne payez rien, les agences publicitaires le feront pour vous. c'est le modèle principale de Google (bien que pas open source ;) ).
Sugar Daddy Ware : Le logiciel a un papa bien veillant. Eclipse est développé par IBM. Open Office par Sun / Oracle. Ne vous souciez de rien, papa est là, il assure l'évolution du logiciel.
Foundation Ware : Le logiciel est supporté par une fondation. Il a beaucoup de contributeurs et de donateurs. Apache, Mozilla, Wikipedia sont parmi les plus connues.
Beg Ware : Donner nous de l'argent, aucune raison invoquées, juste donnez nous de l'argent. c'est le modèle le plus répandu pour les projets de petites tailles.
Tchotchke Ware : Le logiciel est payé par l'achat de goodies (Tshirt, stylo, mug, ...), Allez visiter le magasin en ligne de google ou d'ubuntu
Let’s Make a Deal Ware : Les développeurs supportent le coût de développement jusqu'à ce que d'autres le fasse, Wordpress, Drupal ont commencés comme cela. Sourceforge héberge des tas de projet basés sur ce modèle

Cette liste n'est pas exhaustive. et certains logiciels / distributeurs cumulent les modèles pour maximiser les revenus. Il est cependant à noter que ces modèles sont relativement fragiles et les revenus non maitrisés. Les dons sont assez sporadiques, et le site de wikipédia nous incite souvent à faire des dons en mettant en avant combien "il manque dans la caisse" :

Le monde du libre et du gratuit me parait vraiment être une bonne chose : Lorsque l'on voit encarta qui a fermé son site à cause de Wikipedia, je me dis que la force du libre est la sensation que le travail qu'on fournit va servir à tout le monde. Les gens sont prêts à s'investir si des sociétés ne s'engraissent pas sur leurs dos. Mettre un logiciel en open source apporte son lot d'avantages : on décuple le nombre de personnes, de contributions, d'idées, la réactivité dans la résolution de bugs, et on diminue aussi le nombre de développeurs à payer...

Des problème peuvent également apparaitre. Dans un système décentralisé, lorsque les personnes responsables du projet prennent des chemins différents, comme ce fut le cas de Mambo et Joomla. Dans ce cas une guerre s'ouvre et les utilisateurs subissent les dommages collatéraux : Lequel choisir, le projet est il viable, ne va-t-il pas s'arrêter, quel est le meilleur ? Les problèmes peuvent aussi apparaitre pour les prises de décisions : Quand tout le monde décide, plus rien n'avance si les gens n'arrivent pas à se mettre d'accord.

Je me pose également une question : "En ce qui concerne les données gratuites, à qui appartiennent les données et qui en a la responsabilité" ? une réponse idyllique serait "à tout le monde", sauf que ces données sont bien stockées quelque part, et si ces hébergeurs / fondations venaient à cesser d'héberger ces données, il y aurait toujours les backups, mais qui supporterait le coût de l'hébergement, qui reprendrait ces données ? (une société, une fondation existante ou nouvelle, une personne dont les motivations sont autres?) Les données de Openstreetmap et Geonames, par exemple, me semble quand même bien centralisées (plus que Wikipedia). Si ces sites venaient à fermer il n'y aurait que leurs licences pour les protéger. une protection suffisante ?

Automatiser les interactions avec des scripts shell ou bash

Masclet — Thu, 25 Mar 2010 13:37:00 +0100

Peut être avez vous déjà eu besoin de simuler des réponses à des scripts shell. Par exemple lorsque vous avez un script qui demande une confirmation, un mot de passe ou tout autre intervention humaine, et que vous désirez tester le comportement du script. il existe un outil assez pratique pour le faire qui se nomme expect. Il permet d'automatiser les interactions avec des applications non-GUI (aka : graphiques). plusieurs versions sont disponibles expect-tcl8.3 ou expectk.

Expect est un langage de script pour s'interfacer avec des programmes comme FTP, Telnet, fsck, ssh et d'autres qui ne peuvent normalement pas être automatisée à partir d'un script shell. Il est donc également bon pour automatiser l'exécution de programmes sur des systèmes distants. Il s'installe par apt (debian / Ubuntu) ou yum

apt-get install expectk

Vous devez pour cela lister les questions et explicitement en donner les réponses. les wildcards sont permis afin d'être plus souple sur les questions

Voici un exemple qui répond automatiquement à un script se connectant en SSH (bouh pas bien ! :) )

expect - <<ENDSCRIPT
  spawn ssh $_user@$_server '$_command'
  match_max 100000

  expect {
       "Are you sure you want to continue connecting (yes/no)"
       {
          sleep 1
          send "yes\r"
          exp_continue
       }
       "*password:*"
       {
          sleep 1
          send "PASSWORD\r"
          exp_continue
      }
  }
ENDSCRIPT

En voici un autre pour un SCP :

#!/usr/bin/expect  --
 set timeout 30
 spawn scp user@ip:~/myfile  .
 expect {
                      "password:" {
                                send "password\r"
                    } "yes/no)?" {
                                send "yes\r"
                                set timeout -1
                    } timeout {
                                exit
                    } eof {
                                exit
                    }
 }

Combiné avec ShUnit, il permet d'automatiser les tests facilement.

Détecter et corriger les fuites mémoire java

Masclet — Mon, 01 Mar 2010 09:16:00 +0100

Ceux qui ont déjà développé en C, puis en Java auront probablement apprécié la gestion de la mémoire par la JVM. En effet, Java masque la complexité de la gestion de la mémoire aux développeurs. Cette tache est déléguée au garbage Collector. Cependant même si cette gestion est dite 'automatique', cela ne permet pas de faire n'importe quoi. Que ce soit en C, Java, ou un autre langage, la mémoire est une ressource limitée ! En java lorsque la JVM n'a plus assez de mémoire pour s'exécuter, elle génère une Erreur java.lang.OutOfMemoryError.

Plusieurs cas sont alors possible :

Soit vous n'avez pas alloué assez de mémoire à la JVM
Soit votre code a ce qu'on appelle un fuite mémoire

Si vous êtes dans le premier cas, les choses se résolvent assez facilement : il vous suffit d'allouer plus de mémoire grâce aux paramètres -Xmx, -Xms et -XX:PermSize (ou de modifier le code pour qu'il gaspille moins de mémoire). Dans le deuxième cas vous allez devoir trouver où se situe la fuite mémoire. Si vous avez utilisé des logiciels pour vous y aider, vous avez peut être été perdu par toutes les possibilités qu'ils offrent et par la profusion d'informations qu'il fournissent.

Le but de ce billet est d'expliquer comment détecter et corriger les fuites mémoires avec Eclipse Memory Analyser Tool un outil gratuit et très utile qui aide vraiment à trouver les fuites mémoires. Nous allons voir comment extraire les informations pertinentes, les comprendre, et trouver les responsables des fuites mémoire en ayant une approche pragmatique. Je vous propose de nous appuyer sur du code simple (disponible en fichier attaché à ce billet) générant une fuite mémoire.

La gestion de la mémoire en Java

La JVM dispose de plusieurs zones mémoire distinctes :

La pile (ou heap), est l'espace mémoire où tous les objets et tableaux sont stockés. Lorsque la JVM démarre, la pile est initialisée à la valeur spécifiée par -Xms et elle grandira dynamiquement quand les objets seront crées, jusqu'à ce qu'elle atteigne sa taille maximale spécifiée par le paramètre -Xmx. Si la taille maximale est atteinte, et que plus de mémoire est nécessaire, la JVM générera une java.lang.OutOfMemoryError: Java heap space.
Permgen space : il s'agit de l'espace mémoire qui est alloué pour le chargement des classes (pas les objets). A la différence de la pile, la taille de cette région est fixe et ne varie plus après le démarrage de la JVM. Pour la JVM de Sun, la taille par défaut du permGen space est de 64M. Vous pouvez changer cette valeur grâce au paramètre -XX:PermSize. Rappelons tout de même que les options commençant par XX ne sont pas des paramètres HotSpot stables et que leurs compatibilités dépendent du vendeur et de la version de la JVM. Si la mémoire du permgen est insuffisante une java.lang.OutOfMemoryError: PermGen space sera renvoyée
il existe un troisième type d'erreurs : les erreurs natives. Elles apparaissent lorsque le système hôte ne peut plus fournir de mémoire (plus assez de place en mémoire vive, ou plus assez de swap). Dans ce cas la JVM génère une Erreur java.lang.OutOfMemoryError: request <size> bytes for <reason>.

Cas des champs statiques : Les champs statiques ne peuvent être garbage collectés tant que la classe qui les référence est chargée. il ne peuvent être garbage collectés que lorsque le class loader qui est responsable du chargement de la classe est lui même garbage collecté.

Chaque instance de classe a une taille en mémoire, cette taille appelée "Shallow Heap" est constituée de types primitifs (int, char, ...). Une instance peut avoir également des références sur d'autres objets qui ont eux même une taille. Les objets ainsi liés entre eux constituent un graphe.

Tous les graphes disposent d'une racine d'attache, ces racines peuvent être, par exemple, des threads ou des class loaders qui tiennent des références sur les attributs statiques. Ces racines se nomment en anglais des "GC root". Toutes les instances en mémoire finissent par être attachées à une racine, si ce n'est pas le cas, le Garbage Collector peut supprimer ces instances du graphe, et libérer de la mémoire.

Les références peuvent être de plusieurs types. Il y avait les références fortes "StrongReference" et depuis java 5 il existe des références dites douces "SoftReference" : L'objet est référencé, mais si la JVM a besoin de mémoire, elle peut libérer cet objet. On trouve également les références légères "WeakReference": L'objet restera en mémoire, tant qu'il existe une référence forte ou douce sur lui. enfin il existe des PhantomReference : les objets peuvent être supprimés de la mémoire si aucune référence forte, douce, ou légère existe sur cette objet.

Empreinte de la mémoire (Heap dump)

Afin de permettre des diagnostiques et de voir ce que contient la mémoire de la JVM, il est possible de générer une "empreinte de la mémoire" qui correspond à tous les objets chargés à un instant précis. Ces empreintes sont plus connus sous le nom de "Heap dump".

Ces dumps contiennent :

Tous les objets : champs, références, et objet primitifs.
Toutes les classes : Class loader, super Class, champs statiques

En revanche il ne contient pas les informations sur qui et où sont crées les objets, ni quels sont les objets qui ont déjà été garbage collectés.

Il existe différentes méthodes pour générer ces dumps. Soit en spécifiant les options -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump.hprof au lancement de la JVM afin qu'un dump soit généré lorsqu'une java.lang.OutOfMemoryError survient. Notez toutefois que comme toutes les options commençant par XX, elles sont dépendantes du vendeur de JVM. La deuxième solution est de faire un dump à la demande, à l'aide du JDK 6 et de JConsole. les dumps à la demande sont utiles, par exemples, après des benchs.

Voici la procédure :

Lancez JConsole situé dans le répertoire "bin" de la JVM
Sélectionnez le processus Java pour lequel vous voulez faire le dump. Vérifiez sur l'onglet "VM summary" que c'est bien le bon processus.
Rendez vous sur l'onglet Mbeans
Sélectionnez l'item com.sun.management / hotspot diagnostic / operation / dumpheap
Spécifiez le chemin complet du fichier où vous voulez stocker le dump dans le premier champs de saisie (laissez le deuxième champs à true). Les dumps ont souvent l'extension hprof, et MAT ne verra pas le fichier s'il n'a pas la bonne extension.
Validez en cliquant sur le bouton "dumpHeap". Cela figera l'exécution de la JVM (donc à éviter en production), exécutera un garbage collector, et générera un fichier binaire avec le contenu de la mémoire.

Si vous ne possedez pas JDK 6.0, il est possible d'utiliser jmap :

jmap -heap:format=b <PID_DU_PROCESS_JAVA>

Qu'est ce qu'une fuite mémoire

Une fuite mémoire est une dérive non contrôlée de l'utilisation de la mémoire. elle est souvent due à un objet qui garde des références à une multitude d'autres, ce qui empêche le garbage collector de les enlever de la mémoire. Cette dernière grandit alors de plus en plus et finit par saturer.

Pour comprendre une fuite mémoire il faut connaitre quelques termes (en anglais):

Dominator tree : Liste des plus gros objets et de qui les référencent.
Leak suspect : Objet ayant une grosse taille dans le dominator tree.
Accumulation point : Gros objet référençant beaucoup d'autres petits objets

Voici un représentation graphique des termes évoqués ci dessus :

Shallow Heap et retained Heap : il s'agit de la taille que prend un objet sur la pile. "shallow heap" représente la taille des éléments de l'objet sans inclure les objets qu'il référence, tandis que "retained Heap" les prend en compte : elle représente la taille qui sera libéré si cet objet est garbage collecté. Voici un exemple pour mieux comprendre :

Ci dessous ce trouve la représentation interne d'une string que j'ai pu obtenir avec le mode debug d'Eclipse :

On voit qu'une string est représentée par trois entiers : count, hash, et offset, qui représente la shallow heap, ainsi qu'une référence "value" à un tableau de char . count, hash, offset et value représente la retained heap car le char sera également garbage collecté si la string l'est aussi.

Eclipse Memory Analyser Tool

Il existe déjà des outils permettant d'analyser les dumps, mais ils sont soit difficiles d'approche comme jhat (Java Heap Analysis Tool) et jmap soit ils sont payants comme Jprofiler.

Eclipse a développé un outil permettant d'analyser les heap dumps. Cela permet d'aider à trouver où se situent les fuites mémoires et de détecter les gaspillages et améliorations possibles de l'utilisation de la mémoire. L'outil ne se contente pas de vous analyser la mémoire, il cherche également où peuvent se situer les fuites ainsi que les optimisations. c'est là le point fort de cet outil.

MAT peut être installé en tant que plugin dans Eclipse, ce qui a l'avantage de pouvoir regarder le code en même temps que de regarder le dump, ou en tant que client lourd (RCP) à part entière, des scripts sont alors disponibles en plus du plugins. Peu importe votre choix, vous pouvez vous rendre sur cette page pour le télécharger.

Utilisation de MAT avec un code d'exemple

Je vous propose de tester MAT avec du code simple (disponible en fichier attaché à ce billet) générant une fuite mémoire. Le code représentera plusieurs objets métiers : une entreprise, des salariés, et des adresses, ainsi qu'une classe permettant de générer quelques instances de ces objets et une HashMap statique servant de cache pour les objets Entreprise. Enfin une fois tous ces objets chargés, je provoquerai une fuite mémoire en remplissant un tableau avec des Double. Je dis bien "provoquerai", car à la différence des Exceptions, les Errors sont générées par la JVM et non par le code : si je fais

throw new OutOfMemoryError();

et que je spécifie les options HeapDumpOnOutOfMemoryError le dump ne sera pas généré.

je lance donc la classe Application avec les options -XX:+HeapDumpOnOutOfMemoryError -Xms5m -Xmx10m -XX:MaxPermSize=256m.

En l'absence de HeapDumpPath, c'est un fichier avec le PID qui sera généré, l'avantage étant qu'un nouveau fichier de dump sera généré à chaque java.lang.OutOfMemoryError (il ne sera pas écrasé puisque le nom sera différent à chaque fois)

Le lancement du programme me donne la sortie suivante :

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid2331.hprof ...
Heap dump file created [13486084 bytes in 0.401 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.ArrayList.ensureCapacity(ArrayList.java:169)
        at java.util.ArrayList.add(ArrayList.java:351)
        at com.demo.mat.OutOfMemoryHelper.addDouble(OutOfMemoryHelper.java:18)
        at com.demo.mat.OutOfMemoryHelper.throwOutOfMemoryError(OutOfMemoryHelper.java:13)
        at com.demo.mat.Application.main(Application.java:74)

Il ne reste plus qu'a analyser le dump. vous pouvez l'ouvrir directement en lançant MAT, puis en allant dans File->Open Heap Dump et en sélectionnant le fichier java_pid2331.hprof. (seuls les fichiers .hprof apparaitrons). MAT générera alors plusieurs indexes et un rapport HTML. Les indexes permettent de naviguer plus rapidement car le format hprof n'est pas très exploitable en l'état. Cette génération n'aura lieu qu'une seul fois et lorsque vous rouvrirez ce dump, Mat utilisera les fichier déjà générés.

Dans notre cas le fichier sera de 10 méga octets (environ taille du Xmx), mais si vous voulez analyser de gros fichiers je vous conseille d'utiliser la ligne de commande:

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse java_pid2331.hprof

car MAT a des fois du mal à les digérer. L'ouverture par MAT sera alors plus rapide et facile.

vous pouvez aussi utiliser le scipt ParseHeapDump.sh, il vous faudra par contre remplacer les ^M, pour cela ouvrez le fichier en mod binaire avec VIM :

vim - b ParseHeapDump.sh
puis :%s/<CTRL+V><CTRL+M>//g pour remplacer le ^M par chaine vide

Prise en main de l'outil

Le rapport donne une première vue avec

les informations sur la taille du dump (8.7M) et le nombre de classe chargées (360)
un camembert représentant les plus gros objets en mémoire. En passant votre souris sur chaque partie du camembert, vous pouvez avoir des informations sur les attributs (références et champs natifs) de l'objet dans la colonne de gauche 'attributes'

Différentes actions menant vers différentes vues du dump :

Un histogramme : qui affiche une représentation de l'utilisation mémoire par classes (nombre d'objets instanciés par classe, ainsi que leurs tailles 'shallow' et 'retained'). Vous pouvez d'ailleurs voir que le nombre de char est sensiblement le même que le nombre de String ;)
Un dominator tree (voir définition ci dessus) : présente non plus une vue par classes mais par objets
Une vue graphique des objets du dominator tree groupés selon différents critères : class loaders, packages, classes. Le dominator tree travaille, si on ne spécifie pas de groupage, au niveau objet
Une liste des classes chargées plusieurs fois par différents class loader.

Les parties les plus intéressantes du rapport et les plus exploitables directement sont sans aucun doute les deux rapports suivants:

Liste des 'leak suspects', c'est à dire que l'outil vous suggère où peuvent se situer les responsables de fuites mémoires.
Une liste des objets gaspillant la mémoire (e.g : ArrayList surdimensionnées ayant beaucoup d'éléments vides) avec des suggestions d'optimisations de l'utilisation mémoire (à ne pas confondre avec le rapports des fuites mémoires.)

Voyons vue par vue, les choses que nous pouvons faire : Dans toutes les vues vous avez la possibilité de voir ce que contient l'objet sélectionné dans l'onglet "attributes".

Il est possible de calculer la taille de la 'retained heap' via l'icône représentant un calculatrice.

Vous pouvez ainsi trier les objets par 'retained heap' pour identifier les 'leak supect'. Vous pouvez aussi les filtrés en rentrant des expressions régulières juste en dessous des libellés de colonnes (e.g : "regex" en dessous de 'Class Name'). Attention pour les regexp, elles sont sensibles à la casse.

Une action qui révèle souvent des informations intéressantes, consiste à grouper les objets. Si vous les groupez par classe, vous pouvez par exemple obtenir le nombre d'objets et le pourcentage de la mémoire totale qu'occupe les objets de cette classe. Cela permet d'identifier les points d'accumulation plus facilement lorsque la fuite mémoire ne concerne pas un seul gros objet (ce qui n'est pas notre cas) mais une multitude d'objets de la même classe. Par défaut, la distribution de l'occupation de la mémoire ce fait par objet, en les groupant, les shallow / retained heap sont alors additionnés, laissant souvent voir une répartition inégale de l'utilisation de la mémoire selon les classes (en savoir plus). Vous pouvez aussi les grouper par class loader, ce qui peut se révéler intéressant pour des webapps, Tomcat, par exemple, utilise des class loader differents : webappClassLoader et un SystemClassLoader (en savoir plus). OSGI (voir l'article publié précédemment) utilise aussi beaucoup de class loader différents

Explication des menus

Lorsque vous cliquez droit sur les objets du dominator tree ou sur les classes de l'histogramme, vous obtenez un menu vous permettant d'avoir des informations sur l'élément sélectionné :

List objects=>with outgoing references: objets référencés par l'élément sélectionné. Si on additionne la taille de ces objets, on obtient la retained size.
List objects=>with incomming references : objets qui référencent l'élément sélectionné.

La liste des objets est contextuelle à l'élément sélectionné : si les objets sont groupés par classe, ou que l'élément est une classe, une ligne par objet de cette classe sera affichée, si l'élément est un objet, alors seuls les objets concernés par cet objet (référencé par / qui référence) seront affichés

List class => by outgoing references : les classes des objets référencés par l'élément.
List class => by Incoming references : Les classes des objets qui ont une référence sur l'élément

La liste des classes affichée est également contextuelle. Exemple pour outgoing référence : si l'élément sélectionné est une classe, alors la liste de toutes les classes référencées par tous les objets de cette classe sera listée, si l'élément est un objet, seule la liste des classes référencées par cet objet sera affichée.

Path to GC root => Affiche les chemins des objets qui référence cet objet jusqu'à leur élément racine (un peu comme les incomming objects mais moins en profondeur car s'arrête lorsque l'on arrive au sommet de la pile du thread auquel appartient l'élément). Il est possible via les sous menus de filtrer selon les weak / soft / hard références. ce qui peut être utile lorsque vous utilisez des caches d'objets avec des références soft, car vous pouvez uniquement inspecter l'élément en tenant compte ou pas du cache. Ce menu n'est applicable que pour un objet pas pour classe.

Merge Path to GC root : affiche le chemin le plus court parmi les références racines pour chaque instance de la classe ou de l'objet sélectionné

Java basics permet d'avoir des renseignements divers sur l'objet (e.g : chercher une String). Depuis la version 0.8, il est possible d'analyser les stacktraces. Ces informations sont disponibles via le menu java basics=>threads stacks

Java collections sert plus à détecter les gaspillages de mémoire. il permet par exemple d'avoir le ratio de remplissage d'un tableau.

Leak identification=> Component Report : permet d'avoir des informations sur la mémoire occupée par cette objet : taille que l'objet ou que les objets d'une classe occupent dans la pile, leurs soft et leurs hard références,

Leak identification=> Top consumer : les plus gros éléments regroupés et triés selon différents critères : Objet, Classe, Class loader, Package. il permet d'avoir une répartition des objets par classe (e.g : trouver quels sont les plus gros objets de la classe Salariés). ce menu est utile lorsque vous l'appliquez sur une classe, car il montre quels sont les plus gros objets de cette classe et leurs répartitions

Immediate dominator : Donne les classes des objets qui font que l'élément est gardé en mémoire (e.g : les immediate dominators de char sont bien souvent des String). Il est souvent utile de filtrer les classes des package com.sun.* et java.* car on peut supposer que la fuite ne vienne pas de là. Dans l'exemple ci dessous, pour les immediate dominator de char, si on considère la ligne concernant Entreprise : La première colonne donne le nombre d'objets de la classe listée (1), la deuxième donne le nombre d'objets référencés par cette classe (3) (un objet Entreprise référence 3 char correspondant aux trois commentaires).

Show retained set : donne le nombre d'objets que référence l'élément, groupés par classe. le retained set représente les objets qui seront libérés si l'élément est garbage collecté. Pour un objet Entreprise, il contient 3 char, 3 Strings et une Entreprise (les trois commentaires+ la class ). vous pouvez filtrer le retained set par le ou les noms des champs. On peut alors se demander "Pourquoi les objets "raison social", "salariés" ne sont pas dans la retained set alors qu'on les voit si on liste les outgoing objects de Entreprise. La réponse est que ces objets ne seront pas libérés si Entreprise disparait. Pour le prouver faites un incomming référence sur les objet de Entreprise : les commentaires ne sont uniquement référencés par Entreprise, alors que raison social par exemple est également référencé comme clé pour la Hashmap de cacheEntreprise. De même pour "raison social" qui est une constante car déclarée dans le code, alors que les 3 commentaires sont générés au runtime.

Savoir lire les graphes

Lorsque l'on est devant un graphe, il est important de savoir le lire. prenons l'exemple pour des 'outgoing références' :

La classe Entreprise à des référence vers 4 objets de type String qui se nomme 'commentaire', 'commentaire2', commentaire3, et 'raison social'. et une ArrayList qui se nome salarié. si l'un des objet avait une valeur null, il n'aurait pas été listé.

Voyons maintenant comment lire des 'incoming références' :

L'objet entreprise (je dis bien objet et pas classe) est référencé par :

Le champs 'entreprise' de 3 objets de type Salarié,
Le thread lui même , correspondant à la déclaration de la variable (Entreprise entreprise = new Entreprise() )
Le champs 'value' d'une HashMap, correspondant à la HashMap de cache nommée entreprise et appartenant à la classe CacheEntreprise .

Lorsque l'on analyse des dumps mémoire, il est fortement conseillé de connaitre la représentation interne des objets Map, Collections, String, etc. Cela permet de mieux naviguer. Une HashMap est par exemple constitué d'un tableau de hashMapEntry, lui même constitué de champs key, value, et hash. Si vous voulez explorer un objet, allez sur l'onglet 'attributes', cliquez droit, puis sélectionnez 'Go into' :

Les rapports de fuites mémoires

Entrons maintenant dans le vif du sujet. Le rapport proposant des responsables des fuites mémoires. Comment cela fonctionne ? En fait l'outil analyse le dump et recherche les 'Leak suspects', Il commence par chercher les points d'accumulation en analysant les écarts significatifs dans la retained size entre deux objets du graphe, puis remonte les 'incomming references', prend le plus court chemin, et en déduit le suspect.

Un rapport HTML comprenant plusieurs sections est alors généré :

les points d'accumulation : donnent les informations sur la taille et le type d'objets, le thread incriminé, et le nombre d'objets contenus.

Le rapport génère aussi une liste de mots clés permettant de le googliser ou de les taper dans un bug tracker. L'idée est à mon sens excellente : Lorsque vous créez le bug, vous y ajoutez ces mots clés, et une personne qui désire retrouver ce bug ou voir si une résolution a déjà été trouvée, tape ces mots clés, retrouve le bug et une potentielle résolution éprouvée.

Deux questions se posent alors :

Qui garde une référence à cet objet ?
Pourquoi l'objet est si gros et que contient il ?

Pour la première question on va chercher quel est le plus court chemin du GC root jusqu'à l'objet du point d'accumulation :

Le graphe ce lit 'ligne du haut' est contenu par 'ligne du dessous'. Dans l'exemple ci dessus : le tableau d'objet est référencé par le thread (Chemin le plus court) et par une ArrayList

Pour la deuxième question MAT nous donne un aperçu des objets référencés par le point d'accumulation. Cela permet en général d'avoir une idée plus précise de la cause de la fuite.

Le rapport fournit également une répartition des objets référencé par le point d'accumulation par classes. Dans notre cas, le tableau d'objet ne contient que des Double, ce qui laisse à penser qu'une méthode remplit le tableau.

Une autre information intéressante est l'environnement d'exécution. Dans quel contexte a eu lieu le dump. Cela à une importance quand vous utilisez -XX:HeapDumpOnOutOfMemoryError . Les informations importantes sont entre autres :

Les propriétés de la JVM (Xms, Xmx). Peut être un mauvais dimensionnement de la mémoire ?
Le nombre de threads et leurs tailles permettent de voir si un seul thread est incriminé, et dans ce cas, selon la nature de traitement qu'à le thread, vous pouvez plus cibler la fuite (exemple : un thread de purge d'un cache)
L'histogramme des classes peut également donner des informations sur la cause. S'il existe un grand nombre d'objets appartenant à un classe d'un de vos package, il est probable (pas à 100%, mais vous disposez déjà d'une piste) que la fuite est causée par du code vous appartenant.

Informations sur les threads

MAT fournit des informations sur le context d'exécution des threads. il inspecte les variables threadLocal et selon ce qu'il y trouve, nous donne des informations supplémentaires. exemple :

s'il trouve des objets sur des requêtes HTTP il inspectera l'objet et en extraira les headers, URL, status code, etc.
s'il trouve des connections JDBC, il extraira les resultsets, query,...on peut par exemple voir qu'il manque un clause where, ce qui fait que beaucoup trop d'objets sont rapatriés, et cause une trop grande consommation mémoire
s'il trouve des contexts OSGI, il explorera leurs contenus.

Voici deux exemples : le premier pour un thread exécutant une requête SQL :

le deuxième pour un thread exécutant une requête soap :

On peut légitimement se poser la question "comment sont déterminer ces informations ? " en fait si le suspect est un thread, il explore son nom (exemple "HTTP-processor" pour un thread Tomcat, "RMI TCP Connection(8)-127.0.0.1 pour un connecteur jmx, "Timer-3" pour un timerThread), il inspecte les variables threadLocal et selon ce qu'il y trouve nous donne des informations supplémentaires. Ce système d'exploration est basé sur un système de plugins, vous pouvez donc en créer vous même selon vos besoins

OQL ou Object Query Language

Pour permetre de rechercher des objets facilement, vous pouvez les rechercher avec une syntaxe SQL like. Exemple :

select e.nom from com.demo.mat.Entreprise e

Vous pouvez utiliser des clauses WHERE, des UNION, des projections (avg, min, max,...). vraiment très pratique pour trouver, compter, avoir des statistiques sur des objets en particulier. (en savoir plus)

Voilà pour la théorie :) j'espère que vous maitrisez les différents concepts de l'outil et que vous savez désormais aller chercher les informations pertinentes.

Le prochain post sera basé sur un cas concret et expliquera comment j'ai résolu une fuite mémoire sur Gisgraphy, en 15 minutes à l'aide de MAT.

Nouveau look aux idées larges !

Masclet — Sat, 27 Feb 2010 15:56:00 +0100

Le blog à désormais un nouveau look. oh... pas très très différent. Je suis juste partie du thème précédent et j'ai changé le style pour l'adapter aux styles des billets : c'est-à-dire des articles techniques.

En effet en regardant les statistiques des résolutions d'écran des utilisateurs, J'ai remarqué que personne n'était en 800*600, alors que le thème était optimisé pour une résolution 800*600. J'ai donc augmenté la largeur de la colonne centrale en diminuant les marges de chaque coté, attribué plus de place à la colonne de contenu, et diminué la colonne avec les rubriques, qui me semblait moins importantes que le contenu. A mon sens, le texte est beaucoup plus lisible. Pour les zone de code, j'ai également opté pour une couleur jaune, plus sympathique que le gris. Faites moi part de vos impressions, et des éventuels problèmes rencontrés.

Tester du code en ligne

Masclet — Thu, 04 Feb 2010 15:35:00 +0100

Certains connaissent peut être pastebin qui permet d'envoyer du code à quelqu'un (ou d'un PC à l'autre ;) ) en générant une shortURL. Il existe des sites qui vont plus loin en permettant de tester du code directement en ligne : http://codepad.org/. il suffit de copier / coller votre code, et le site vous le compile et vous l'interprète. c'est le cas de codepad

Il supporte les langages suivants :

C
C++
D
Haskell
Lua
OCaml
PHP
Perl
Plain Text
Python
Ruby
Scheme
Tcl

Vous pouvez mettre votre code "privé", ce qui est pratique, car j'ai déjà retrouvé du code, que je ne voulais pas partager publiquement, indexé par Google, après l'avoir envoyé via pastebin)

Dans la même lignée, il existe des sites plus spécialisés pour tester les interactions HTML<=>Javascript : http://jsbin.com/. Son utilisation est triviale : vous avez le code javascript à gauche et le code HTML à droite.

Le site va beaucoup plus loin que pastebin, d'une part, car il est spécialisé dans un langage, mais aussi parce qu' il offre la possibilité :

De sauvegarder votre code.
D'inclure des librairies connues, comme Prototype, Jquery, Mootools, Dojo et de choisir parmi différentes versions
De générer une short URL de votre code (exemple : http://jsbin.com/ilomu3)
De modifier un code existant en cliquant sur ''Edit using JS Bin" en haut à droite (j'avoue c'est pas flagrant :) ).
De gérer plusieurs versions d'un même code

L'avantage est qu'il permet de tester du code avant de mettre à jour un librairie (exemple : passer de Prototype 1.6.03 à 1.6.1.0), de vous faire la main sur des librairies, ou de partager du code entre collègues.

iPad nano

Masclet — Mon, 01 Feb 2010 11:25:00 +0100

Pour faire suite à mon post Stratégie d'Apple vs stratégie Google, je vous propose une image qui m'a fait bien rire

Sinon, je vous conseille la lecture de ce billet sur l'ipad et son effet d'annonce manqué

Tester le javascript : JSUnit, JSmock, Jstester (partie 2)

Masclet — Tue, 26 Jan 2010 13:16:00 +0100

Après le billet consacré à JsUnit et celui qui expliquait comment mocker une requête Ajax, nous allons maintenant voir comment mocker en javascript. Pour cela je vous propose une courte présentation de JsMock. Les exemples de code sont en annexe de ce billet.

Pour montrer les capacités de JsMock, rien de tel que des exemples de code. Nous allons donc reprendre le code du premier billet (vous pouvez télécharger les sources en annexe du premier billet)

Installation

La première chose à faire est de télécharger JsMock et de l'ajouter dans le répertoire JsUnit (ou ailleurs, mais le tout est d'être cohérent lors de la déclaration dans le fichier HTML) , puis de l'importer à partir de notre fichier de tests SimpleCodeTest :

<script language="JavaScript" type="text/javascript" src="../jsmock.js"></script>

Exemple de code à mocker

Pour comprendre les mocks il vaux mieux faire interagir deux objets entre eux : cela permet de tester un objet et d'en mocker un autre. Ajoutons donc un objet ConfigParameter et définissons en une instance dans MyObjectToTest :

function ConfigParameter() {
        this.getAlertMessage = function(){
                return "alertMessage";
        }

        this.setParam = function(Aname, Avalue) {
                //this[name]=value
        }
}

function MyObjectToTest(){
        this.configParameter = new ConfigParameter();

        var message = "Not defined yet!";
        
        this.setMessage = function(messageParam){
                message = messageParam
        }

        this.getMessage = function(){
                return message;
        }

        this.getAlertMessage = function(){
               return this.configParameter.getAlertMessage();
        }

        this.setConfigValue = function(){
                this.configParameter.setParam("MyName", "MyValue");
        }

}

Mocker des valeurs de retour

Voici un exemple où nous allons mocker le retour de getAlertMessage :

function testMockReturnedValue() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andReturn("mock Alert Message");

        MyObj.configParameter = mockConfig;

        // Assert
        assertEquals("mock Alert Message", MyObj.getAlertMessage());
        
        mockControl.verify();
}

Vous remarquerez qu'à la différence de EasyMock en Java, il n'est pas nécessaire d'appeler la méthode replay()

La méthode vérify permet de vérifier que les méthodes mockées sont bien appelées le bon nombre de fois : si une méthode non défini par votre mock est appelée le test ne passera pas, en revanche vous pourriez avoir défini le comportement d'une méthode mais que cette dernière ne soit jamais appelée, dans ce cas, si vous n'appelez pas la méthode verify, le test passera mais vous ne saurez pas que la méthode n'a pas été appelée).

mocker des fonctions

Il est possible de simuler les comportement (le corps de la méthode) d'une fonction grâce à la méthode andStub :

function testStubFunction() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andStub(
                 function() { 
                        return "test";
                 } 
        );

        MyObj.configParameter = mockConfig;

        // Assert
        assertEquals("test", MyObj.getAlertMessage());
}

Simuler des exceptions

Il est également possible de simuler des exceptions avec la méthode andThrow :

function testThrow() {
        exception = false ;
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andThrow("Error !");

        MyObj.configParameter = mockConfig;

        try {   
        MyObj.getAlertMessage();
        } catch (e){
          exception = true;
        }

        assertEquals(true, exception);
}

Mocker des fonctions avec paramètres

Pour mocker une fonction avec des paramètres, vous avez deux possibilités : soit vous spécifiez le type des paramètres lors de la définition du mock, dans le cas où seul le type des paramètres vous importe. Pour cela utiliser TypeOf.isA()

function testFunctionWithTypedParameters() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().setParam(TypeOf.isA(String),TypeOf.isA(String));

        MyObj.configParameter = mockConfig;


        MyObj.setConfigValue();

        mockControl.verify();
}

soit vous spécifiez la valeur des paramètres, si vous voulez vérifier que la fonction est appelée avec les bonnes valeurs :

function testFunctionWithParameters() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().setParam("MyName", "MyValue");

        MyObj.configParameter = mockConfig;
        MyObj.setConfigValue();

        mockControl.verify();
}

J'espère que cela vous à donner envie de l'utiliser, car le Javascript est de plus en plus présent dans les applications web et les tests permettent de mieux découpler votre code et de le rendre plus robuste.

La troisième et dernière partie traitera de JsTester qui permet de tester du javascript coté serveur (JsUnit dispose d'une partie serveur mais elle n'est là que pour piloter les tests, il faut toujours avoir un navigateur). nous verrons ses avantages et ses inconvénients et comment l'intégrer avec Maven et JUnit.