Publié le 12 février 2008 par Thomas Recloux
Dans des articles précédents, je découvrais les fonctionnalité de Jetty 6 et de Tomcat 6 pour déconnecter les requêtes HTTP de leur Thread de traitement, ce qui permet de mettre en place de manière efficace du « poll » longue durée depuis un client AJAX, ce qui revient presque a pouvoir faire du « push » du serveur vers le client.
La cinématique est la suivante :
- Le client initie une connexion HTTP vers le serveur, en tache de fond à l’aide du composant XmlHttpRequest ou d’une iFrame cachée
- Le serveur reçoit la requête et n’envoie une réponse au client que quand un événement est à présenter.
- Si au bout de quelques dizaines de secondes le serveur n’a pas d’évènements à pousser vers le client, il renvoie tout de même une réponse qui indique au client de renouveler sa requête afin d’utiliser une connexion fraîche.
Ce modèle de programmation (appelé COMET) a été monté en charge et les resultats sont très bons, moins d’une demi seconde de temps de latence sous une charge très importante.
Google utilise cette technique pour le chat intégré à GMail avec apparement un timeout de l’ordre de 30 secondes. Le client léger (appelé GAD) de la plateforme de call center Genesys d’Alcatel Lucent utilise aussi ce mécanisme avec un timeout de l’ordre 10 secondes
Tags: comet | Aucun commentaire »
Publié le 1 février 2008 par Thomas Recloux
Après avoir découvert les continuations de jetty, voici les Advanced IO de Tomcat.
Le modèle de programmation permet aussi de déconnecter les Thread des connexion HTTP, la mise en œuvre me semble un peu plus complexe que pour Jetty mais permet un contrôle plus fin des évènements de la connexion.
Tags: comet, java, tomcat | Un commentaire »
Publié le 15 janvier 2008 par Thomas Recloux
Il y a 4 ans, j’avais été chargé d’une étude sur le « push » en client léger, le but était de pouvoir notifier les utilisateurs d’évènements importants.
Comme le protocole HTTP est basé sur un système de requêtes / réponses, qui s’apparente à du « pull », le serveur ne peut pas déclencher d’évènements en direction du client. L’idée est donc de faire en sorte que le client vérifie régulièrement si le serveur veut lui présenter un évènement.
J’avais implémenté un système de « pooling » HTTP avec une servlet qui se mettait en attente sur un conteneur de messages pour une durée de plusieurs dizaines de secondes avant de retourner une réponse au navigateur qui s’empressait de déclencher une nouvelle requête. Bien sur, l’inconvénient majeur de cette architecture est que chaque utilisateur bloque un Thread coté serveur, ce qui est gourmand en ressources.
Avec les applications AJAX, les besoins de ce type se multiplient. Heureusement les nouvelles implémentations d’I/O Java permettent de ne pas monopoliser un thread par socket. Il est donc possible d’affecter le thread à une autre tache pendant l’attente d’un évènement.
La version 6 du conteneur de servlet Jetty propose une implémentation de cette solution via les Continuations. Cette API permet de suspendre une requête et de libérer le thread. En général, intégrer des spécificités dans un conteneur web est délicat car il y a un risque : on grève la portabilité vers un autre conteneur. Cependant dans ce cas, l’API est utilisable dans un autre conteneur en basculant dans un classique wait/notify qui bloque le thread. De plus, les continuations vont être proposées au groupe de travail sur les Servlet 3.0 .
Une bonne nouvelle pour les applications de type CTI qui pourront se passer d’Applet et autres ActiveX.
Via ongwt.
Tags: comet, java, jetty | Un commentaire »
