10
votes

Quartz & Spring - regroupé mais pas persistant?

Dans mon application de printemps, j'utilise le SchedulerFactoryBean pour intégrer à quartz. Nous allons avoir des instances Tomcat en cluster, et donc je souhaite avoir un environnement de quartz en cluster, de sorte que les mêmes travaux ne fonctionnent pas en même temps sur différents serveurs Web.

Pour ce faire, mon app-context.xml est comme suit: xxx

Tout fonctionne bien, sauf que lorsque je tente de supprimer ou de modifier une gâchette, puis de redémarrer mon application, le Les vieux déclencheurs sont toujours persistés dans la DB et sont toujours courus. Je ne veux pas cela, je veux juste qu'ils soient supprimés lorsque l'application s'arrête (ou est redémarrée). J'ai défini la valeur du overwieeExistingjobs pour être vrai, car je pensais que c'est ce qu'il a fait.

Des idées? Tout ce que je veux utiliser le DB pour le regroupement, et non une sorte de persistance au-delà de cela.


1 commentaires

J'ai eu le même problème et je n'ai pas pu trouver de solution. Enfin, j'ai déplacé le travail de l'application Web et la programma pour courir via Cron. Curieux de voir ce que les autres ont à dire.


3 Réponses :


2
votes

J'ai fait des recherches sur le sujet et c'est un bogue bien connu de quartz, j'ai trouvé quelques postes sur leur forum. Pour résoudre ce problème, j'ai créé un haricot qui supprime tous les enregistrements de la table de quartz. Vous pouvez appeler ce haricot avant que votre haricot de quartz ne soit chargé (Ajoutez un «dépend-on» sur votre haricot de planificateur) lorsque votre contexte de printemps est en cours de détruit (assurez-vous que le pool de connexion DB est toujours ouvert), ou manuellement à travers une forme de UI. Il y a aussi un bogue sur les groupes d'emplois, ne soyez pas surpris. Mon premier correctif consistait à créer un pot de quartz client avec le correctif, mais il a été assez difficile de mettre à niveau chaque fois qu'ils ont publié une nouvelle version (j'utilisais 1,4 ou 1,5 à l'époque - ne vous souvenez pas).


1 commentaires

Ce n'est pas un bug. C'est une idée fausse de ce que le plugin qui lit le fichier XML fait. Tout ce qu'il contient le fichier et ajoutez les travaux / déclencheurs spécifiés dans le fichier. C'est tout ce qu'il fait de temps qu'il court. Il ne prétend rien faire autre chose que cela (par exemple, effacez d'abord toutes les données du planificateur).



0
votes

C'est un ancien poste, mais dans l'intérêt de ceux qui ont besoin d'une solution, c'est ici. Spécifiez «VRAI» pour la propriété «OwnwieExistingJobs». Vous devrez redémarrer votre serveur et chaque fois que vous redémarrez, les anciens travaux seront supprimés. Je ne sais pas si cela était possible dans les anciennes versions de Quartz-Scheduler, j'utilise 2.1.7


0 commentaires

1
votes

J'ai rencontré un problème similaire avec du quartz en cluster. Je n'exécutais pas de chameau, mais c'est le même problème.

1) Il n'est pas possible de supprimer les emplois dans un environnement en cluster en retirant simplement les travaux / déclencheurs du contexte de printemps XML.

2) Parce que la base de données stocke les informations de travail / déclencheur, les déploiements de roulement à travers les serveurs deviennent problématiques si vous ajoutez ou modifiez des travaux. Les serveurs peuvent commencer à exécuter des travaux avant que la mise en œuvre du travail puisse être déployée sur le serveur d'applications, à moins que vous ne soyez à tous les serveurs avant de déployer vos modifications.

Pour résoudre ceci, je suis proposé une solution assez simple. Dans le cadre de notre processus de construction, nous capturions et stockions déjà une version de construction unique + numéro avec l'artefact de construction (à l'aide de la substitution variable de la grade). Pour résoudre ce problème, nous avons simplement apporté le nom du planificateur incluent la version unique de version +. Il en résulte que le dernier ensemble d'emplois + déclencheurs étant ajouté à la DB sous le nom du nouveau planificateur, et une fois le déploiement de rouleau terminé, tous les serveurs sont en cours d'exécution avec le nouveau nom. Cela résout le problème de suppression et résout également le problème de déploiement roulant. Si tous les noms de planificateur supplémentaires deviennent un problème dans la DB, quelque chose pourrait être écrit pour les nettoyer si nécessaire.


0 commentaires