Je reprends un sujet qui avait déjà été discuté entre Nathalie et Arthur hors forum.
Les crontab ne fonctionnent plus correctement depuis environ 6 mois sur AIP.
Elles ne se déclenchent pas à la bonne heure
Par exemple le batch ExportGlobal planifié à 4h : 0 0 4 * * ?
Se lance pour la première fois à 1h40
2016-09-08 01:40:00,032 INFO [STDOUT] 2016-09-08 01:40:00,032|SIMPLICITE|/alstom|ICORECM004|system|com.simplicite.util.CronJob|run||Execute job ExportGlobal at 2016-09-08 01:40:00
Deuxième problème, il se lance plusieurs fois d’affilée
Execute job ExportGlobal at 2016-09-08 01:41:23
Execute job ExportGlobal at 2016-09-08 01:42:45
Execute job ExportGlobal at 2016-09-08 03:50:00
Quand je regarde l’ordonnancement effectué lors du clear cache
2016-09-07 10:00:05,489 INFO [STDOUT] 2016-09-07 10:00:05,489|SIMPLICITE|/alstom|ICORECM003|system|com.simplicite.ejbs.util.CronManager.CronManagerBean|addTrigger||ExportGlobal has been scheduled to run at: Wed Sep 07 10:00:05 CEST 2016 and repeat based on expression: 0 0 4 ? * *
je vois que le prochain lancement est planifié à l’heure du clearcache et non à l’heure indiquée par l’expression crontab.
Je pense que c’est juste un problème de log mais difficile d’être sûre.
Un patch a été livré en Février en maintenant 27 mais ça n’a rien changé au problème.
Nous sommes en 3.0 maintenance 28
Oui il s’agit bien d’un problème de log au démarrage des triggers. Elle affiche la date courante et non celle du prochain run.
Le patch 27 corrige le déclenchement à l’heure prévue. Avant le thread ne se réveillait “qu’à partir” de l’heure prévue mais la JVM ne garantissait pas un démarrage exact (plus un thread dort plus il est long à se faire réveiller). Maintenant on réveille le thread plus souvent pour vérifier l’heure.
Il faut donc maintenant qu’on vérifie le temps de pause calculé avant endormissement, il y peut être un pb à ce niveau là. Pouvez vous nous envoyer les logs pour vérifier les prochaines taches à passer et le délai d’attente calculé ?
Next cron job: ... Cron manager is sleeping for...
Enfin si le job se lance plusieurs fois, c’est soit que ce calcul est faux, soit qu’il y a plusieurs threads de cron : peut-t-on aussi avoir la liste des threads Simplicité (via le monitoring / onglet Threads / bouton filtre “Simplicité” uniquement) ? dans ce cas il faudra voir pourquoi et vos procédures.
J’ai trouvé un projet sur lequel on a aussi plusieurs Cron qui tournent en parallèle, alors qu’un seul démon suffit.
C’est un bug ou un problème de mode opératoire qui produit ce cas.
Ca expliquerait surement que la “date de prochain passage” soit non-thread safe, et donc mal mise à jour en concurrence d’accès car on est pas sensé avoir plusieurs threads.
Je vais chercher d’où ça peut venir mais en attendant
=> il faut bien vérifier qu’un seul thread est présent : "SimpliciteCronThread-xxxx"
sinon il faut redémarrer tomcat/jboss et revérifier.
Le problème a été reproduit et corrigé en maintenance 3.0M30 / 3.1M12 / 3.2M5.
en attendant, il suffit de redémarrer le serveur si plusieurs threads SimpliciteCronThread-<application> sont visibles depuis le monitoring/thread.
Ce cas se produit dans des cas rares de relance de la cron (directement par IHM ou via un clear cache) alors que celle-ci est en état RUNNING : c’est à dire lorsque la cron est en train d’instancier des jobs, l’interrupt de l’ancien thread n’est pas pris en compte et on se retrouve avec 2 threads de cron. Ce traitement a été renforcé pour forcer l’arrêt de l’ancien thread dès que les jobs sont lancés.