Devoxx 2011 : Introduction au Framework AKKA

Suite à la présentation de Play! 2.0 hier, ma curiosité m’a poussé à suivre la présentation d’Akka par Jonas Boner afin d’en savoir plus sur les mécanismes se cachant derrière tout ça.

Akka, en dehors de la déesse de la sagesse et de la beauté dans la mythologie Sami, est un framework disponible en Scala et en Java permettant de gérer très efficacement des applications multithread et concurrentes. Ce framework est OpenSource et soutenu par TypeSafe, la société derrière Scala.

Malgré un speaker pas forcément au top de sa forme, le contenu de la présentation a été très intéressant en présentant des problématiques de plus en plus courante et une manière différente de la stack Java habituelle pour les résoudre.

Le but de Akka est de proposer un framework simple et unifié pour gérer la concurrence, la surcharge des systèmes et offrir une architecture scalable de manière transparente.

La présentation a été faite sur Akka 2.0 qui est prévu en début d’année prochaine. La plus part des concepts que je détaille dans l’article sont déjà présent dans la version actuelle d’Akka mais ont été grandement simplifiés dans la prochaine version.

La présentation s’est focalisée sur le concept d’acteur qui n’est pas la seule solution proposée par Akka pour répondre aux problématiques ci-dessus mais qui est la principale et la plus connue.

Le principe des acteurs est de créer un objet très léger et peu couteux à instancier.  Chaque objet est un récepteur qui attend des messages qui lui seront envoyés par un autre acteur. Tout étant asynchrone, l’ensemble est très performant pour traiter de nombreuses interactions.  Ainsi les acteurs passent leur temps à communiquer les uns avec les autres et à réagir en fonction des évènements reçus. Un thread pool s’occupe de gérer tous ces acteurs afin de leur permettre de dépiler leurs files à tour de rôle soit de manière unitaire, soit par lots en fonction de la configuration.

Encore mieux, les acteurs peuvent être répartis sur plusieurs noeuds Akka et donc être distribués de manière extrêmement simple. Le runtime Akka s’occupe de dispatcher les acteurs sur les noeuds, et si besoin vous pouvez définir combien d’instance de chaque acteur tourne et sur quels noeuds.

Cela permet de faire des applications scalables sans avoir besoin de faire autre chose qu’ajouter un simple fichier de configuration. En effet en interne vous ne manipulez pas directement les Acteurs mais un object ActorRef qui représente une référence, au sens Akka, de votre acteur. C’est cet objet qui sait où envoyer votre message en fonction de votre configuration.

Chaque acteur peut donc recevoir des messages (action receive), en envoyer (action tell)  mais également vouloir le résultat d’un envois (action ask). Dans ce cas, le tell renvois un Future qui contiendra la valeur de retour du traitement.

Cependant, Akka a revu en grande partie la gestion des Futures tels que nous les connaissons en Java pour les rendre complètement non bloquants. Chaque futur possède des callbacks qui seront déclenchés lorsque la valeur est disponible, une erreur survient, etc. Il est bien évidement toujours possible de bloquer jusqu’à la réception du résultat, mais également d’agréger directement et simplement plusieurs Futures.

Ce fonctionnement est encore une fois impressionnant de simplicité et d’efficacité pour gérer des programmes multithreadés.

La présentation a également portée sur la gestion des défaillances au niveau des acteurs. Là encore l’approche est très différente du try/catch habituel en Java. Nous avons à la place un arbre des acteurs, chaque parent étant responsable de traiter les défaillances de ses enfants (en fonction des exceptions levées). Un mécanisme de gestion des défaillances très simple (mais pas simpliste) est disponible sur chaque acteur afin de pouvoir définir que faire en cas de défaillance d’un enfant. Il est également possible de dire que quand un enfant échoue, tous les enfants sont impactés. La politique par défaut étant de simplement détruire l’acteur ayant échoué et d’en créer un nouveau.

Une fois tous ces concepts autour des acteurs présentés, Jonas a laissé la main à l’équipe Play! qui à rejouer la partie de conférence de la veille consacrée au traitement des données en asynchrone.

Enfin il a fini en présentant la stack TypeSafe. Pour ces deux sujets, je vous invite à lire l’article sur Play! 2.0 pour en savoir plus.

En conclusion, Akka m’a vraiment impressionné dans sa manière simple et efficace de résoudre des problèmes habituellement complexes. Il m’a également encore plus donné envie d’approfondir l’ensemble de la stack TypeSafe. En effet l’apport de la syntaxe Scala sur ce genre d’application est réellement impressionnant pour sa concision.

Les slides sont déjà disponibles :