Déception @Asynchrone avec Jboss AS 6

  • Sharebar

Génigraph est partenaire Red Hat, et nous sommes friand des technologies JBoss : elles sont parmi ce qui se fait de mieux sur le marché, nous en sommes convaincus :

  • Convaincus, par nos expériences,
  • Convaincus, parce que la communauté nous en fait l’écho.

Mais parfois, un simple besoin utilisateur peut engendrer de petites déceptions …

J’ai la chance de participer à un projet qui met en œuvre le fleuron de la technologie Java :
EJB 3.1, Context and Dependency Injection,  JSF2, et j’en passe, tout ça sur une plateforme JBoss AS 6.1 Final.
Bref, tout pour être heureux.

Architecte en charge l’intégration de briques technologiques dans le projet et actuellement sur la conception d’un moteur d’exécution de traitements batchs, je lorgnais déjà depuis quelques temps sur cette nouvelle annotation @Asynchronous, introduite avec EJB 3.1.

Celle-ci permet d’indiquer que l’exécution d’un service EJB doit se faire de manière asynchrone. Elle permet surtout d’obtenir en retour immédiat un Future (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html) qui donne la main sur le thread d’exécution du service.

Très intéressant dans mon cas puisque les traitements exécutés sur le moteur peuvent prendre un certain temps et que l’Utilisateur, dans sa grande sagesse, a exprimé le besoin de pouvoir arrêter l’exécution du traitement à tout instant.

Et jusqu’à présent, avec les EJB, ça n’était pas possible ! Tout le monde sait que jouer avec les threads instanciés par le serveur JEE, c’est mal. Jamais personne n’oserait killer le thread d’exécution d’un EJB, en tout cas pas sans avoir conscience des conséquences irréversibles que cela peut avoir sur l’état du serveur… Une fois un service invoquer, on avait jusqu’alors qu’à attendre qu’il aboutisse.

Enfin j’allais pouvoir killer un service EJB, le rêve. Formulé de façon plus diplomatique, enfin il était possible d’arrêter proprement un service en cours d’exécution.

Pour illustrer, voilà à quoi peut ressembler l’implémentation d’un service asynchrone :

@Stateless
public class MonService {
@Asynchronous
public Future<String> faireQuelqueChoseDeTresTresLong()  {
thread.sleep(10000000); //très très long
String result = "j'ai bien dormi";
return new AsyncResult<String>(result);
}
}

Génial, avec ça je peux donc très simplement arrêter l’exécution de mon service quand je le souhaite par un appel à cancel(boolean) sur mon Future, dont j’ai conservé au chaud la référence.

Ca devrait fonctionner, les spécifications JEE6 sont formelles, mais malheureusement, ça ne fonctionne pas. L’appel à cancel reste sans effet…

Je cherche donc dans mon moteur de recherche préféré à voir si je me suis loupé quelque part, s’il y a  une subtilité qui m’aurait échappé, si c’est un problème connu de JBoss 6, …

Et quelle n’est pas ma surprise de lire (https://community.jboss.org/thread/177433#647108):

“@Asynchronous support in AS 6.x was not fully completed. I would recommend that you use AS 7.1.x and report any issues that you encounter. AS7 has fully functional @Asynchronous feature.”

Je comprends pas… pour moi il est évident que JBoss 6 est certifié JEE6, c’est justement là-dessus que se base sa réputation : le 1er serveur JEE OpenSource certifié ! Et là j’apprends qu’une fonctionnalité telle que les EJB asynchrone, présentée comme une des grosses améliorations de JEE6, n’est pas supportée ?!

Et bien effectivement, difficile à croire mais JBoss 6 n’est pas “Full Java EE 6 Certified”, mais uniquement “Java EE 6 Web Profile Certified” et ça fait une grosse différence !

Je vous laisse lire https://community.jboss.org/thread/160813 et https://community.jboss.org/thread/162247, discussions enflammées pour mieux comprendre le pourquoi du comment. Et aussi le résultat d’une enquête sur les attentes concernant la certification de JBoss exprimées par la communauté et les utilisateurs http://blog.webagesolutions.com/archives/357

D’où ma déception : JBoss 6 n’est pas “Full Java EE 6 Certified”  …. c’est a savoir !!!

Je ne suis bien évidemment pas le seul à être surpris de l’apprendre ; Je fais quoi moi maintenant ? Je passe en version 7…?

PS : tout est parti du dernier Java Magazine de Juillet-Août 2012, avec un article très intéressant sur le threading et la concurrence en JEE6, je vous laisse apprécier : http://www.oraclejavamagazine-digital.com/javamagazine/20120708/?pg=59&pm=1&u1=friend#pg59

This entry was posted in JEE, JEE6, Java. Bookmark the permalink.

One Response to Déception @Asynchrone avec Jboss AS 6

  1. Stuart Smith says:

    Pardon my English reply but I saw your link back to our blog and wanted to offer another blog post that might help clear up version confusion with JBoss.


    http://blog.webagesolutions.com/archives/466

    This blog post talks about the different versions of JBoss out there right now (very confusing!) and thoughts on which ones to use. There is a big difference between JBoss AS (open source) and JBoss EAP (supported platform). It doesn’t help though that both have a “version 6″ but are very different.

    I’ll leave the details to the blog post above but suffice to say that I would use JBoss AS 7.x over JBoss AS 6.x for a number of reasons.

Leave a Reply