Beaucoup de questions intéressantes :-). Je vais essayer de répondre dans l'ordre.
Quelles sont les raisons qui poussent à ce qu'une tâche ne soit pas dans un serveur d'application ?
Un serveur d'application permet de gérer beaucoup de tâches courtes et rapidement. Il possède un nombre de thread limité. Prenons par exemple une édition PDF un peu lourde qui demande 5 minutes de génération. Dès qu'un utilisateur clic dessus un thread du serveur est scotché. Plusieurs utilisateurs et le serveur d'appli est bloqué. Sans parler du fait que l'utilisateur, devant son écran en cours de chargement pendant 5 minutes va rappuyer plusieurs fois et accélérer la course vers la catastrophe.
[...] les serveurs d’application WebSphere et Glassfish (prochainement Tomcat) pour l'API cliente [...]
L'API cliente pour soumettre des jobs a été testée avec GlassFish et Websphere. Pour Tomcat il y a encore des petits pépins pour récupérer la connexion à la base de donnée. Les déclarations JNDI diffèrent entre ces serveurs d'applications. Merci Java, write once, debug everywhere :-)
[...] gère les ressources JNDI pour les bases de données et les brokers de messages.
JQM est un serveur JNDI pour les batch afin de leur fournir l'accès à des bases de données, des broker de message ou même des répertoires (ce qui est classique pour des batch qui créés des fichiers.
Ça marche avec du polling des nœud de traitement ? Donc toute la capacité de monté en charge est déportée sur la base de données et on prend une charge importante même quand on a rien à faire (si on a beaucoup de nœuds de traitement), non ?
Oui, cela fonctionne par polling. Cela ne pose pas de problème pour monter en charge dans la plupart des cas. Chaque moteur possède plusieurs slots de traitement. Il y a donc un polling par moteur (=1 JVM).
Clairement, JQM n'est pas fait pour faire du grid computing pour faire un serveur batch d'une application. Une installation typique comporte 4 à 6 moteurs avec une fréquence de polling entre 1 sec pour les plus courts et 1 minute pour les plus lents. Pas de quoi faire éternuer une base de données :-)
Plus généralement, j'ai du mal à voir l'intérêt face à JMS. Il est tout à fait possible de gérer des traitements de ce genre via des files JMS distribuée. Un avantage des MDB c'est la possibilité de placer les traitements (envoi d'autres messages JMS et accès en base de données) dans une transaction. Il est possible de manipuler les files via JMX.
C'était une autre possibilité. Mais les MDB sont toutefois peu adaptés aux traitements long et ne permettent pas de gérer certaines fonctionnalités comme l'annulation de lancements mulitples. Quant à la gestion des transactions avec les MDBs... ok, pas de troll.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Beaucoup de questions intéressantes :-). Je vais essayer de répondre dans l'ordre.
Un serveur d'application permet de gérer beaucoup de tâches courtes et rapidement. Il possède un nombre de thread limité. Prenons par exemple une édition PDF un peu lourde qui demande 5 minutes de génération. Dès qu'un utilisateur clic dessus un thread du serveur est scotché. Plusieurs utilisateurs et le serveur d'appli est bloqué. Sans parler du fait que l'utilisateur, devant son écran en cours de chargement pendant 5 minutes va rappuyer plusieurs fois et accélérer la course vers la catastrophe.
L'API cliente pour soumettre des jobs a été testée avec GlassFish et Websphere. Pour Tomcat il y a encore des petits pépins pour récupérer la connexion à la base de donnée. Les déclarations JNDI diffèrent entre ces serveurs d'applications. Merci Java, write once, debug everywhere :-)
JQM est un serveur JNDI pour les batch afin de leur fournir l'accès à des bases de données, des broker de message ou même des répertoires (ce qui est classique pour des batch qui créés des fichiers.
Oui, cela fonctionne par polling. Cela ne pose pas de problème pour monter en charge dans la plupart des cas. Chaque moteur possède plusieurs slots de traitement. Il y a donc un polling par moteur (=1 JVM).
Clairement, JQM n'est pas fait pour faire du grid computing pour faire un serveur batch d'une application. Une installation typique comporte 4 à 6 moteurs avec une fréquence de polling entre 1 sec pour les plus courts et 1 minute pour les plus lents. Pas de quoi faire éternuer une base de données :-)
C'était une autre possibilité. Mais les MDB sont toutefois peu adaptés aux traitements long et ne permettent pas de gérer certaines fonctionnalités comme l'annulation de lancements mulitples. Quant à la gestion des transactions avec les MDBs... ok, pas de troll.