Version imprimable
Bonjour,
Je travaille sur une appli qui est deployee sur de nombreuses machines en production. Je dois utiliser Quartz afin de fournir une tache, qui parcoure la databse et envoie des emails a nos utilisateurs. Cette tache doit etre executee chaque soir. Le probleme est que si je deploie ce nouveau code sur chacune des machines, alors j'enverrai autant de mail que j'ai de machines en production.
Est-ce que quelqu'un a deja eu affaire a ce genre de problemes?
Merci beaucoup.
J'imagine que tu es "obligé" de :
- deployer sur plusieurs machine ton appli
- que tu ne peux dissocier la partie quartz de ton appli dans une autre appli ?
Donc il faut que centralise le faite que le traitement ai été effectué ==> ajout d'une table des "déjà fait" et integration de cette table dans ton traitement. Mais personnelement je trouve cela très dommage, il serait mieux de pouvoir changer un des 2 points de ma précédente hypothèse.
Louis
Oui malheureusement, je ne peux pas changer mes contraintes.
Mais comment etre sur que mes differentes instances ne travaillent pas sur les memes donnees. La tache va etre planifiee pour etre executer a 24:00 tous les jours. Toutes les mahcines ayant rigoureusement la meme heure, j'ai peur que les travaux se chevauchent, et je ne sais pas comment mettre de verrou sur ma base.
L'ideal serait que l'execution de tes taches quartz ne soit fait que par une seul machine.
Chacune de tes machine de prod ajouterais leur job. mais une seule lancerais l'exécution. As-tu une problématique de temps réelle? si oui Quartz n'est peut être pas adapter car si plusieurs job sont lancer simultanément et que tu n'a pas assez de thread simultanée une partie de tes jobs vont attendre qu'une thread se libère.
Une autre solution pour possible pour ton problème de mail est de lancer un job supplémentaire à partir de minuit qui va vérifier régulièrement si toutes les jobs sont terminés si oui il en vois le mail et se reprogramme pour le lendemain sinon il se reprogramme pour dans 5 min par ex ou 1 heure çà dépend de la durée de tes jobs.
C'est meme certain ==> de mémoire avec oracle il existe une syntaxe :Citation:
Envoyé par bourbaki2003
lock table ... mais si tu accede avec un select simple sur la table ayant le lock il est possible que cela ne marche pas (à vérifier)
Mais cela reste très très m... comme solution. Le mieux de faire sauter le "verrou fonctionnelle" ;)
Tant que tu ne peux changer ton appli tu n'a pas de solution fiable.
Une tache quartz n'es pas identifié par son heure mais par son nom et son groupe si sur chaque machine tu as un nom de tache différent c bon.Citation:
Envoyé par bourbaki2003
Oui mais le probleme c'est que bien qu'elles aient des noms differents, elles s'executeront en meme temps.Citation:
Envoyé par moritan
oups j'avais mal compris c'est de ton jeu de donnée que tu parlais et nom pas des job quartz.
Si tu centralise l'exécution des job quartz, tu as la possibilité de réduire le nombre de jobs simultanée à 1 et comme ça les tâches ne s'enchaineront sans se perturber.
C'est bien la le probleme, je ne peux pas les centraliser.Citation:
Envoyé par moritan
J'ai cru comprendre qu'il ne pouvait malheureusement modifier cela :cry:Citation:
Envoyé par moritan
Pas assez rapide à poster ma réponse :oops:
Tu ne peux pas dire qu'une seule des machine effectuera l'ensemble du traitement?Citation:
Envoyé par bourbaki2003
Si tu utilises la même base pour Quartz sur chacune des machines et ne démarre le moteur que sur une seule, ça devrait marcher.
Car l'api te permet d'ajouter des taches sans avoir démarrer le moteur Quartz.
Le probleme est que le build et le deploiement sont automatiques. Donc je ne peux pas specifier que telle ou telle partie de mon code doit etre deployee sur une instance particuliere.
Rien ne t'empêche de tout déployer sur chacune de tes instances.Citation:
Envoyé par bourbaki2003
utilise ensuite un fichier properties pour dire si tu lances ou pas ton moteur quartz.
Tu le coupe en valeur par défaut lors du déploiement et tu l'actives à la main sur un seul serveur.
Après quartz peut tourner en mode cluster, peut-être qu'on peut gérer le nombre de thread globale, je ne sais faudrait regarder dans la doc.
Néanmoins tu auras toujours des problème car tu veux qu'une applis distribuée marche en mode client serveur...
Il serait quand même bien pour la suite de mettre en place un serveur pas forcément dédié mais unique pour quartz, ne serait-ce que pour avoir une archi applicative clean et maintenable.
C'est vrai que c'est une solution, meme si j'aimerais eviter au maximum les interventions manuelles.
Tu peux aussi mettre l'ip de la machine que lancera le moteur dans le properties.Citation:
Envoyé par bourbaki2003
Au lancement de l'appli tu compare l'ip du properties et l'ip e la machine si différent tu ne lances pas le moteur si = tu le lances.
Comme ça pas de manip après le déploiement.
Mais ça reste une solution moins bien que de faire 2 applis une qui ajoute les taches sur toutes les machine et une qui les traite sur une seule.
Je viens de parler avec les mecs qui s'occupent du deploiment de l'appli en prod. Apparemment, ils peuvent manuellement deployer un artifact sur une machine particuliere.
Je pense donc creer soit un nouveau WAR ou EAR, qui fera parti du build mais pas du deploiment. Il sera deploye automatiquement par les mecs en charge des releases.
Donc lors du deploiment, Quartz sera automatiquement instancie, et les jobs ajoutes au scheduler.
Qu'en pensez vous?
Je ne comprends pas ce que tu veux dire.Citation:
Envoyé par bourbaki2003
Louis
Qu'est ce que tu ne comprends pas exactement?
Qu'appels tu exactement un artifact ? (http://fr.wikipedia.org/wiki/Artefact)
Et qu'est ce qui est au final deployer sur tes serveurs ?
Louis
Un artifact est un object issu du build (jar, war, ear...).
Au final, on deploie un ear (ejbs, wars, jars) pour la partie back end et un war pour le cote front-end.
Donc si je comprends bien tu aura sommairement :
1 conteneur web contenant l'ihm en frontal
----||----||----||----||----||----||-----
1 conteneur d'EJB contenant outre ta partie business de ton appli ta partie scheduler
Cette partie scheduler sera seulement ici ? si oui alors tu ne devrait pas avoir de pb - sinon alors je n'ai pas compris :oops:
Louis
Le seul probleme c'est que je ne travaille pas avec une machine mais un parc de machine, et je ne peux pas deployer mon scheduler sur toutes les machines sinon ca ne marchera pas. De plus le deployment etant automatique, c'est assez genant de devoir deployer manuellement qqchose sur une machine specifique.
Donc je n'ai pas compris tu aura donc :
n serveur en front end
et
n serveur en back end qui contiennent quartz
et qui vont potentielement faire tous le meme job au même moment (envoyer les même mails)
?
Tu viens de re-inventer le spamming :lol:
désolé !
Pour moi si tu peux déploiyer sur une machine spécifique, c'est
déploiement sur n machine d'une appli que ajoute des taches dans quartz
déploiement sur une seul machine d'une appli qui lance le moteur quartz.
Toutes ont le même properties de conf de quartz évidemment.
Sinon c'est la solution que je t'ai dit en mettant un properties dans le déploiement contenant l'ip de la machine qui a le droit de démarrer quartz