Après des batch aussi énormes que ce dont tu parle ça n'est pas forcément très courant.
Ça va vite même sans être la NSA… dès que tu as plusieurs centaines de milliers de lignes à insérer ou mettre à jour, tu vas avoir très très envie de gérer des commits intermédiaires pour des raisons de perf. Et donc de te passer de la gestion des transactions des middlewares pour gérer tes points de reprise. C'est donc à adapter en fonction de chaque type de batch et de sa volumétrie.
Et quand tu as plus ? (des messages JMS envoyé et des commits en base par exemple)
Cela fait toujours deux ressources managers :-)
Blague à part, tant que tu es dans une logique tout ou rien, le code reste simple. Si de toute façon tu veux commencer à gérer finement les transactions en fonction des cas d'erreur, tu devras passer en mode manuel.
De plus, si tu as beaucoup (>>2) de ressources managers à coordonner, le coût du XA va également augmenter… et il faut sans doute se demander s'il est bien raisonnable de gérer autant de ressources synchronisées dans une seule transaction. En cas de pépin, la resynchro sera pénible (et XA ou pas, il y a toujours des cas ou on doit le faire, donc autant avoir un système robuste…).
Je ne dis qu'XA est inutile dans l'absolu (et mettre en place du XA aujourd'hui est moins aléatoire qu'il y a 10 ans) ; cela s'évalue au cas par cas comme tu le soulignes, mais dans 99% des cas c'est un réel overkill qui amène son lot de bug et de complexité car les gens ont peur de gérer deux malheureuses transactions à la main ou font du XA par conformisme (2 transactions=>XA…). Heureusement, cela n'est pas une fatalité.
Quand tu as deux transactions avec deux resources managers, l'algo n'est pas du tout diabolique. En particulier dans le cas de la lecture d'un message JMS et l'écriture en base. En gros :
- début transaction JMS, lecture du message
- début transaction base de données
- traitement…
- si tout va bien : commit base de données puis commit broker JMS
- si tout va mal : rollback des deux.
Bon, maintenant, le pire cas, que se passe-t-il quand, pas de pot (cas rare, mais qui peu exister) ton serveur meurt lamentablement entre les deux commits. Cela fait que ta transaction en base est validée, mais ta transaction avec ton broker est en rollback. Donc, à la prochaine exécution ton code lira pour la seconde fois le même message. Soit ce n'est pas gênant (youpi), soit c'est un problème, dans ce cas il faut pouvoir le gérer (identifiant fonctionnel, etc.).
Simple à coder, simple à débugguer. Pas de dépendance sur des trucs compliqués. Pas de risque de tout casser lors d'un patch ou d'une montée de version (du moins pas à ce niveau :-)).
Non, c'est une illusion… XA coûte réellement en mise en place, tests, debug et en perf. De plus, dès qu'on traite un peu de volume on va avoir envie de gérer plusieurs transactions. Enfin, une application se doit bien souvent de traiter les cas de doublons applicatifs en cas de réémission par l'expéditeur. Alors autant avoir un seul mécanisme fiable au niveau applicatif avec des statuts d'exécution et des identifiants fiables que (trop) se reposer sur les middlewares.
C'est une des raisons qui nous a poussé à avoir une JVM capable de gérer plusieurs workers. Cela facilite la gestion et une partie des problèmes que tu soulèves.
Pour la HA nous avons tout simplement plusieurs instances de moteurs JQM sur différentes machines en écoute sur la même file de job en base.
Le fonctionnement des MDB pousse à utiliser JTA, faire des transactions XA entre plusieurs ressources manager (base de données et broker de message).
Dans les faits, c'est une galère pas possible à mettre en marche et de plus c'est horriblement lent. Il est préférable de gérer deux transactions séparés, manuellement (bean managed) et de gérer au niveau applicatif le cas d'un crash entre les deux commits (c'est à dire un doublon si les commits sont dans le bon ordre).
SprintBatch est compatible EE… cela veut dire deux framework de dév pour les développeurs. Et quid d'un morceau de code qui est utilisé à la fois en batch et en interactif ? C'est un peu mélanger l'eau et le feu.
En me relisant, mon message était peu clair. Je parlais de l'avancement interne du batch (pour annoncer je suis à 30% des lignes traitées par exemple) et non du process. JQM permet également d'enregistrer les résultats du job (un fichier PDF généré par exemple) pour ensuite servir le résultat en http.
Sinon, l'API de base est la même, bien entendu, c'est celle de l'OS. Mais ensuite c'est peu brut de décoffrage en Java pour par exemple gérer une communication inter process ou gérer un verrou etc. Il faut tout se refaire à la main. Il y a peut-être des lib tierces qui font ce boulot, je ne les connais pas. C'est là que le module multiprocess de Python rend les choses sympas. La gestion d'un process ressemble à celle d'un thread (même si le développeur a intérêt à comprendre la différence !).
Pour des tâches longues et gourmandes, tu as parfaitement raison. Nous avons cherché une seule solution pour l'ensemble. Au risque qu'elle ne soit parfaite pour personne.
Nous avons en effet du gérer un class loader par batch et avoir un filet pour attraper les exceptions. Par contre, les bêtises comme l'explosion des fd restent une faiblesse.
Rien n'empêche d'avoir un job JQM qui lance une JVM externe, ce n'est pas l'esprit mais rien ne l'empêche. Nous le faisons déjà pour le PL/SQL par exemple (ce qui représente sans doute 1/3 de nos jobs JQM pour l'instant d'ailleurs).
C'est mieux que cela n'a été oui :-). Mais ça ne fait toujours pas rêver, surtout quand on pense au passage d'arguments ou à la communication inter-process. Le batch a tout de même des interactions avec le moteur : reporting d'état d'avancement, gestion de l'arrêt (kill), etc.
Pour le confort du lancement de process, je pensais plutôt à http://docs.python.org/2/library/subprocess.html et http://docs.python.org/2/library/multiprocessing.html
Il reste encore un peu de chemin :-).
Pour des batchs long, le coût CPU est négligeable, tu as raison même si le coût que tu indiques est pour une JVM « vide ». Charge quelques lib et le temps s'allonge… Depuis quelques temps la JVM ne charge plus tout le rt.jar, ce qui donne un temps à vide plutôt sympa. Malheureusement les développeurs ne sont pas économes en chargement de lib :-).
De plus, dans notre cas d'usage, nous devons gérer à la fois des batchs longs et des batch courts voir très courts (1 à 2 sec) mais nombreux (>100 000 par heure en pic).
Dans un pur cas de batch long, nous aurions sans doute opté pour une JVM externe. La gestion d'un pool de thread avec un classloader spécifique n'a pas été la partie la plus facile du dév :-)
JQM n'est pas un scheduler. C'est une file d'attente de job et un conteneur d'exécution distribué.
Les jobs soumis à JQM peuvent provenir d'un scheduler, d'un flux (arrivée d'un fichier, un message…) ou une action utilisateur sur l'écran d'une application.
Ces deux produits sont donc différents et répondent à deux besoins différents (et potentiellement complémentaires).
Le coût de démarrage a certe réduit, mais il n'est pas négligeable pour autant. De plus il faut toujours un élément actif pour lancer le process, donc une JVM qui lance une JVM heu… Par ailleurs, il est plus facile de manager un thread qu'un process en java (ce n'est pas le cas avec d'autres langages…).
De plus, il y a tout de même un impact mémoire qui n'est pas nul.
Spring Batch et JavaBatch définissent surtout une structure de batch (gestion des paramètres, découpage en sous tâches, normalisation des codes retours…) mais ni un conteneur ni une file batch ; ce qui est l'objet de JQM.
Nous étions sur un projet avec une stack EE6, donc ni spring ni EE7, Néanmoins l'étude la JSR352 a été une source d'inspiration et il y aurait intérêt à se rapprocher le plus possible de la norme. Néanmoins une implémentation complète de la JSR352 représentait trop de boulot dans le délai imparti. Mais c'est une reflexion intéressante à inscrire dans la roadmap de JQM. Tout en se rappelant que JQM fait des choses que JSR352 ne propose pas.
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.
Je te remercie d'avoir remonté un pb en 2004… Cela ne donne pas pour autant une bénédiction pour pour tirer sur l'ambulance. Ce n'est pas une manière de faire. Surtout dans un journal public. Ta critique est aveugle et sans discernement…. Il y a des parties avec des erreurs et il faut les corriger. D'autres parties sont relues et de grande qualité.
Comment veux-tu motiver une équipe si elle se fait critiquer de la sorte ?
Critique bien peu constructive et surtout très injuste. Il y a plus de 200 000 chaînes à traduire pour KDE. C'est un travail énorme et globalement de bonne qualité. Mais cela n'empêche pas que des fautes ou des traductions lourdes se glissent…
Quand tu vois une traduction fautive ou perfectible, merci de le remonter aux intéressés (liste kde-francophone@kde.org ou via un bug sur http://bugs.kde.org) plutôt que de râler sur linuxfr.
Et encore, plus lourd en mémoire… c'est très discutable. Le process plasma-desktop consomme ~ 80 Mo de RAM (RSS). Ce n'est pas bien obcène pour 2012 tout de même.
La phrase précédente de cette citation est tout aussi amusante : « The fact is that Gnome leads the evolution of open Desktops and the rest are just following. Just check the competition ».
Tout est dit non ?
Il est bien dommage que certains passent plus de temps à dire du mal des autres (KDE, XFCE, Unity…) qu'à faire des choses utiles. Heureusement,la plupart des Gnomies ne sont pas comme cela. La compétition est globalement saine.
Dans tous les cas, dans ta VM tu utilises un driver particulier fourni par ton hyperviseur (virtual box guest addition, vmware-tools etc.).
Celui-ci fait ensuite une redirection vers le driver graphique de ton host.
Les drivers graphiques dans une VM... et bien ils correspondent à la carte virtuelle de la VM. Donc bien entendu le driver proprio d'une carte graphique ne sert à rien.
D'une part, ceci est souvent factorisé dans les morceaux standard de menu pour les bureaux (GNOME, KDE...). Il n'y a donc qu'une seule traduction à faire pour beaucoup de termes.
D'autre part, les outils de traduction offre aussi cette fonctionnalité, ceci s'appelle une mémoire de traduction. Lokalize (KDE) propose ce mécanisme. Je te rassure, nous ne retraduisons pas 100 fois "ouvrir" ;-).
Enfin, le plus difficile est de converger vers des termes communs pour qu'un bureau linux soit cohérent avec des applications d'origines diverses (OOo, mozilla, gnome, kde...).
Il y a des échanges parfois entre équipes de traduction, mais pas vraiment de coordination forte.
Je te confirme que yokadi permet de gérer des tâches récurrentes. J'ai développé le module de récurrence exprès pour le besoin que tu exprimes !
Je l'utilise pour des choses comme :
- ne pas oublier le payer le loyer de mon parking tous les mois
- faire mon pointage de jours mensuel
- les anniversaires & fêtes
...
Tu peux définir une fréquence quotidienne, hebdo, mensuelle, trimestrielle ou annuelle et qui est définie par une date/heure ou plus complexe (le 3ème lundi de chaque mois...).
Je t'invite à tester Yokadi pour voir si cela correspond bien à ton besoin. De plus, pour te rappeler des échéances, tu peux utiliser le yokadi Daemon qui déclenche une action quand la tâche doit être réalisée (par défaut une notification dans le systray KDE ou gnome, mais tu peux déclencher n'importe quel type d'action, c'est paramétrable).
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Ça va vite même sans être la NSA… dès que tu as plusieurs centaines de milliers de lignes à insérer ou mettre à jour, tu vas avoir très très envie de gérer des commits intermédiaires pour des raisons de perf. Et donc de te passer de la gestion des transactions des middlewares pour gérer tes points de reprise. C'est donc à adapter en fonction de chaque type de batch et de sa volumétrie.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Cela fait toujours deux ressources managers :-)
Blague à part, tant que tu es dans une logique tout ou rien, le code reste simple. Si de toute façon tu veux commencer à gérer finement les transactions en fonction des cas d'erreur, tu devras passer en mode manuel.
De plus, si tu as beaucoup (>>2) de ressources managers à coordonner, le coût du XA va également augmenter… et il faut sans doute se demander s'il est bien raisonnable de gérer autant de ressources synchronisées dans une seule transaction. En cas de pépin, la resynchro sera pénible (et XA ou pas, il y a toujours des cas ou on doit le faire, donc autant avoir un système robuste…).
Je ne dis qu'XA est inutile dans l'absolu (et mettre en place du XA aujourd'hui est moins aléatoire qu'il y a 10 ans) ; cela s'évalue au cas par cas comme tu le soulignes, mais dans 99% des cas c'est un réel overkill qui amène son lot de bug et de complexité car les gens ont peur de gérer deux malheureuses transactions à la main ou font du XA par conformisme (2 transactions=>XA…). Heureusement, cela n'est pas une fatalité.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Quand tu as deux transactions avec deux resources managers, l'algo n'est pas du tout diabolique. En particulier dans le cas de la lecture d'un message JMS et l'écriture en base. En gros :
- début transaction JMS, lecture du message
- début transaction base de données
- traitement…
- si tout va bien : commit base de données puis commit broker JMS
- si tout va mal : rollback des deux.
Bon, maintenant, le pire cas, que se passe-t-il quand, pas de pot (cas rare, mais qui peu exister) ton serveur meurt lamentablement entre les deux commits. Cela fait que ta transaction en base est validée, mais ta transaction avec ton broker est en rollback. Donc, à la prochaine exécution ton code lira pour la seconde fois le même message. Soit ce n'est pas gênant (youpi), soit c'est un problème, dans ce cas il faut pouvoir le gérer (identifiant fonctionnel, etc.).
Simple à coder, simple à débugguer. Pas de dépendance sur des trucs compliqués. Pas de risque de tout casser lors d'un patch ou d'une montée de version (du moins pas à ce niveau :-)).
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Non, c'est une illusion… XA coûte réellement en mise en place, tests, debug et en perf. De plus, dès qu'on traite un peu de volume on va avoir envie de gérer plusieurs transactions. Enfin, une application se doit bien souvent de traiter les cas de doublons applicatifs en cas de réémission par l'expéditeur. Alors autant avoir un seul mécanisme fiable au niveau applicatif avec des statuts d'exécution et des identifiants fiables que (trop) se reposer sur les middlewares.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Merci pour le lien. Cela ne donne pas envie en effet…
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
C'est une des raisons qui nous a poussé à avoir une JVM capable de gérer plusieurs workers. Cela facilite la gestion et une partie des problèmes que tu soulèves.
Pour la HA nous avons tout simplement plusieurs instances de moteurs JQM sur différentes machines en écoute sur la même file de job en base.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Le fonctionnement des MDB pousse à utiliser JTA, faire des transactions XA entre plusieurs ressources manager (base de données et broker de message).
Dans les faits, c'est une galère pas possible à mettre en marche et de plus c'est horriblement lent. Il est préférable de gérer deux transactions séparés, manuellement (bean managed) et de gérer au niveau applicatif le cas d'un crash entre les deux commits (c'est à dire un doublon si les commits sont dans le bon ordre).
SprintBatch est compatible EE… cela veut dire deux framework de dév pour les développeurs. Et quid d'un morceau de code qui est utilisé à la fois en batch et en interactif ? C'est un peu mélanger l'eau et le feu.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
En me relisant, mon message était peu clair. Je parlais de l'avancement interne du batch (pour annoncer je suis à 30% des lignes traitées par exemple) et non du process. JQM permet également d'enregistrer les résultats du job (un fichier PDF généré par exemple) pour ensuite servir le résultat en http.
Sinon, l'API de base est la même, bien entendu, c'est celle de l'OS. Mais ensuite c'est peu brut de décoffrage en Java pour par exemple gérer une communication inter process ou gérer un verrou etc. Il faut tout se refaire à la main. Il y a peut-être des lib tierces qui font ce boulot, je ne les connais pas. C'est là que le module multiprocess de Python rend les choses sympas. La gestion d'un process ressemble à celle d'un thread (même si le développeur a intérêt à comprendre la différence !).
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
Pour des tâches longues et gourmandes, tu as parfaitement raison. Nous avons cherché une seule solution pour l'ensemble. Au risque qu'elle ne soit parfaite pour personne.
Nous avons en effet du gérer un class loader par batch et avoir un filet pour attraper les exceptions. Par contre, les bêtises comme l'explosion des fd restent une faiblesse.
Rien n'empêche d'avoir un job JQM qui lance une JVM externe, ce n'est pas l'esprit mais rien ne l'empêche. Nous le faisons déjà pour le PL/SQL par exemple (ce qui représente sans doute 1/3 de nos jobs JQM pour l'instant d'ailleurs).
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
C'est mieux que cela n'a été oui :-). Mais ça ne fait toujours pas rêver, surtout quand on pense au passage d'arguments ou à la communication inter-process. Le batch a tout de même des interactions avec le moteur : reporting d'état d'avancement, gestion de l'arrêt (kill), etc.
Pour le confort du lancement de process, je pensais plutôt à http://docs.python.org/2/library/subprocess.html et http://docs.python.org/2/library/multiprocessing.html
Il reste encore un peu de chemin :-).
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Pour des batchs long, le coût CPU est négligeable, tu as raison même si le coût que tu indiques est pour une JVM « vide ». Charge quelques lib et le temps s'allonge… Depuis quelques temps la JVM ne charge plus tout le rt.jar, ce qui donne un temps à vide plutôt sympa. Malheureusement les développeurs ne sont pas économes en chargement de lib :-).
De plus, dans notre cas d'usage, nous devons gérer à la fois des batchs longs et des batch courts voir très courts (1 à 2 sec) mais nombreux (>100 000 par heure en pic).
Dans un pur cas de batch long, nous aurions sans doute opté pour une JVM externe. La gestion d'un pool de thread avec un classloader spécifique n'a pas été la partie la plus facile du dév :-)
[^] # Re: Comment JQM se positionne-t-il par rapport à Quartz par exemple ?
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
JQM n'est pas un scheduler. C'est une file d'attente de job et un conteneur d'exécution distribué.
Les jobs soumis à JQM peuvent provenir d'un scheduler, d'un flux (arrivée d'un fichier, un message…) ou une action utilisateur sur l'écran d'une application.
Ces deux produits sont donc différents et répondent à deux besoins différents (et potentiellement complémentaires).
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 2.
Le coût de démarrage a certe réduit, mais il n'est pas négligeable pour autant. De plus il faut toujours un élément actif pour lancer le process, donc une JVM qui lance une JVM heu… Par ailleurs, il est plus facile de manager un thread qu'un process en java (ce n'est pas le cas avec d'autres langages…).
De plus, il y a tout de même un impact mémoire qui n'est pas nul.
[^] # Re: Questions
Posté par Sebastien . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Spring Batch et JavaBatch définissent surtout une structure de batch (gestion des paramètres, découpage en sous tâches, normalisation des codes retours…) mais ni un conteneur ni une file batch ; ce qui est l'objet de JQM.
Nous étions sur un projet avec une stack EE6, donc ni spring ni EE7, Néanmoins l'étude la JSR352 a été une source d'inspiration et il y aurait intérêt à se rapprocher le plus possible de la norme. Néanmoins une implémentation complète de la JSR352 représentait trop de boulot dans le délai imparti. Mais c'est une reflexion intéressante à inscrire dans la roadmap de JQM. Tout en se rappelant que JQM fait des choses que JSR352 ne propose pas.
[^] # 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.
[^] # Re: Hmm
Posté par Sebastien . En réponse au journal Amarok 2.6. Évalué à 4.
Je te remercie d'avoir remonté un pb en 2004… Cela ne donne pas pour autant une bénédiction pour pour tirer sur l'ambulance. Ce n'est pas une manière de faire. Surtout dans un journal public. Ta critique est aveugle et sans discernement…. Il y a des parties avec des erreurs et il faut les corriger. D'autres parties sont relues et de grande qualité.
Comment veux-tu motiver une équipe si elle se fait critiquer de la sorte ?
[^] # Re: Hmm
Posté par Sebastien . En réponse au journal Amarok 2.6. Évalué à 4.
Critique bien peu constructive et surtout très injuste. Il y a plus de 200 000 chaînes à traduire pour KDE. C'est un travail énorme et globalement de bonne qualité. Mais cela n'empêche pas que des fautes ou des traductions lourdes se glissent…
Quand tu vois une traduction fautive ou perfectible, merci de le remonter aux intéressés (liste kde-francophone@kde.org ou via un bug sur http://bugs.kde.org) plutôt que de râler sur linuxfr.
[^] # Re: Est-ce qu'il y a un fond de vrai dans cette citation ?
Posté par Sebastien . En réponse à la dépêche Akademy 2012 et KDE Frameworks 5. Évalué à 2.
Et encore, plus lourd en mémoire… c'est très discutable. Le process plasma-desktop consomme ~ 80 Mo de RAM (RSS). Ce n'est pas bien obcène pour 2012 tout de même.
[^] # Re: Est-ce qu'il y a un fond de vrai dans cette citation ?
Posté par Sebastien . En réponse à la dépêche Akademy 2012 et KDE Frameworks 5. Évalué à 5.
La phrase précédente de cette citation est tout aussi amusante : « The fact is that Gnome leads the evolution of open Desktops and the rest are just following. Just check the competition ».
Tout est dit non ?
Il est bien dommage que certains passent plus de temps à dire du mal des autres (KDE, XFCE, Unity…) qu'à faire des choses utiles. Heureusement,la plupart des Gnomies ne sont pas comme cela. La compétition est globalement saine.
[^] # Re: kplato deviens plan
Posté par Sebastien . En réponse à la dépêche Gestion de planning : LibrePlan... et les autres. Évalué à 2.
Et que le logiciel est traduit en Français (à 97%, il ne manque que 8 chaînes à traduire/vérifier).
Par contre, il n'y plus de mainteneur en ce moment. Donc avis aux volontaires, vous pouvez m'écrire : renard at kde point org.
[^] # Re: les drivers gfx dans une VM..
Posté par Sebastien . En réponse à la dépêche Sortie de la bêta d'Ubuntu 11.04. Évalué à 2.
Dans tous les cas, dans ta VM tu utilises un driver particulier fourni par ton hyperviseur (virtual box guest addition, vmware-tools etc.).
Celui-ci fait ensuite une redirection vers le driver graphique de ton host.
Quelques explications ici :
http://www.virtualbox.org/manual/ch04.html#guestadd-video
a+
# les drivers gfx dans une VM..
Posté par Sebastien . En réponse à la dépêche Sortie de la bêta d'Ubuntu 11.04. Évalué à 5.
Bonjour,
Les drivers graphiques dans une VM... et bien ils correspondent à la carte virtuelle de la VM. Donc bien entendu le driver proprio d'une carte graphique ne sert à rien.
[^] # Re: Système global de traductions libres ?
Posté par Sebastien . En réponse à la dépêche La traduction dans tous ses États libres, compte-rendu . Évalué à 2.
D'une part, ceci est souvent factorisé dans les morceaux standard de menu pour les bureaux (GNOME, KDE...). Il n'y a donc qu'une seule traduction à faire pour beaucoup de termes. D'autre part, les outils de traduction offre aussi cette fonctionnalité, ceci s'appelle une mémoire de traduction. Lokalize (KDE) propose ce mécanisme. Je te rassure, nous ne retraduisons pas 100 fois "ouvrir" ;-).
Enfin, le plus difficile est de converger vers des termes communs pour qu'un bureau linux soit cohérent avec des applications d'origines diverses (OOo, mozilla, gnome, kde...).
Il y a des échanges parfois entre équipes de traduction, mais pas vraiment de coordination forte.
# Quelques liens
Posté par Sebastien . En réponse à la dépêche Conférence Parinux : La traduction dans tous ses états libres le 8 février 2011. Évalué à 2.
http://techbase.kde.org/Localization/Tools/Pology
Pour py10n (outil de gestion de l'équipe de traduction) :
https://github.com/digitalfox/py10n
[^] # Re: TODO list
Posté par Sebastien . En réponse au message Tâches périodiques. Évalué à 1.
Je te confirme que yokadi permet de gérer des tâches récurrentes. J'ai développé le module de récurrence exprès pour le besoin que tu exprimes !
Je l'utilise pour des choses comme :
- ne pas oublier le payer le loyer de mon parking tous les mois
- faire mon pointage de jours mensuel
- les anniversaires & fêtes
...
Tu peux définir une fréquence quotidienne, hebdo, mensuelle, trimestrielle ou annuelle et qui est définie par une date/heure ou plus complexe (le 3ème lundi de chaque mois...).
Je t'invite à tester Yokadi pour voir si cela correspond bien à ton besoin. De plus, pour te rappeler des échéances, tu peux utiliser le yokadi Daemon qui déclenche une action quand la tâche doit être réalisée (par défaut une notification dans le systray KDE ou gnome, mais tu peux déclencher n'importe quel type d'action, c'est paramétrable).
a+