L'objet de mon commentaire est bien de parler des "tâches longues et gourmandes".
Je ne discute pas du bien fondé d'avoir un démon pour exécuter les tâches courtes et fréquentes, je trouve ça pertinent pour tous les arguments que tu développe et même probablement pour d'autres encore.
Je discute le fait d'imposer ce mode de fonctionnement aux traitements lourds, car je pense que c'est une hypothèque sur la robustesse. En effet, les traitements lourds, à un moment ou un autre du cycle de vie des applications, explosent (mémoire/gc, nombre de file descriptors, nombre de connexions base de données, etc.) donc je préfère en terme d'exploitation que quand ils explosent ils n'emportent pas leur petits copains avec eux.
Après, c'est possible dans une certaine mesure d'isoler les traitements lourds mis dans la même JVM mais d'une part c'est dur (affecter des JVM d'exec à certains modules applicatifs, dédiés certaines aux traitements légers et d'autres aux traitements lourds, voire limiter à 1 traitement lourd à la fois dans une JVM, dès que t'as des équipes de dev qui ne se parlent pas ou des versions différentes d'une même appli il faut des class loaders différents par batch, etc.) d'autre part ce n'est pas complètement possible (le nombre de file descriptors et le tas java sont globaux, même avec des class loaders différents et des gestionnaires de sécurité). Du coup la seule façon d'être tranquille c'est de dédier une JVM à un traitement lourd et la façon la plus simple de le faire c'est de lancer la JVM à chaque traitement lourd.
Ça n'empêche pas de traiter les petits/moyens traitements très répétitifs autrement, je ne cherche aucunement à dire le contraire.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par DerekSagan . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 1.
L'objet de mon commentaire est bien de parler des "tâches longues et gourmandes".
Je ne discute pas du bien fondé d'avoir un démon pour exécuter les tâches courtes et fréquentes, je trouve ça pertinent pour tous les arguments que tu développe et même probablement pour d'autres encore.
Je discute le fait d'imposer ce mode de fonctionnement aux traitements lourds, car je pense que c'est une hypothèque sur la robustesse. En effet, les traitements lourds, à un moment ou un autre du cycle de vie des applications, explosent (mémoire/gc, nombre de file descriptors, nombre de connexions base de données, etc.) donc je préfère en terme d'exploitation que quand ils explosent ils n'emportent pas leur petits copains avec eux.
Après, c'est possible dans une certaine mesure d'isoler les traitements lourds mis dans la même JVM mais d'une part c'est dur (affecter des JVM d'exec à certains modules applicatifs, dédiés certaines aux traitements légers et d'autres aux traitements lourds, voire limiter à 1 traitement lourd à la fois dans une JVM, dès que t'as des équipes de dev qui ne se parlent pas ou des versions différentes d'une même appli il faut des class loaders différents par batch, etc.) d'autre part ce n'est pas complètement possible (le nombre de file descriptors et le tas java sont globaux, même avec des class loaders différents et des gestionnaires de sécurité). Du coup la seule façon d'être tranquille c'est de dédier une JVM à un traitement lourd et la façon la plus simple de le faire c'est de lancer la JVM à chaque traitement lourd.
Ça n'empêche pas de traiter les petits/moyens traitements très répétitifs autrement, je ne cherche aucunement à dire le contraire.