Quartz Scheduler: temps d'exécution du trigger incohérents

Question

J'ai quelques applications Java qui utilisent Quartz 1.6.6 sur Weblogic avec Spring (l'une utilise Spring v. 2.5.4, l'autre utilise Spring v. 3.1.1). Mon architecture a deux serveurs d'applications dans le cluster Weblogic.

Les deux applications ont des déclencheurs simples mis en place (en utilisant org.springframework.scheduling.quartz.SchedulerFactoryBean, org.springframework.scheduling.quartz.SimpleTriggerBean et org.springframework.scheduling.quartz.JobDetailBean). Ils sont tous prêts à fonctionner toutes les 60 secondes.

J'ai ajouté la journalisation au org.springframework.scheduling.quartz.QuartzJobBean associé (au début de la méthode executeInternal()) qui écrit l'heure à laquelle le processus est exécuté. Ce que j'ai trouvé est que le temps est incohérent - parfois l'exécution pour une minute donnée n'arrivera pas. Exemples:

Application 1 a un processus de déclenchement qui a été exécuté aux heures suivantes:

14:26:26,098 
14:28:26,089 
14:31:26,096 
14:33:26,093 
14:35:26,095 
14:36:26,098 
14:38:26,103 

Application 2 a deux processus de déclenchement qui ont été exécutés aux heures suivantes:

14:40:05,951 (trigger 1) 
14:41:05,951 (trigger 2) 
14:42:05,943 (trigger 1) 
14:43:05,954 (trigger 2) 
14:44:05,937 (trigger 1) 
14:45:05,956 (trigger 2) 
14:46:05,953 (trigger 2) 
14:47:05,937 (trigger 1) 
14:48:05,941 (trigger 1) 
14:49:05,939 (trigger 1) 
14:50:05,951 (trigger 2) 

Si je désactiver un serveur d'application Weblogic, puis les deux applications exécutent très heureusement tous leurs travaux chaque minute.

J'ai vérifié les tables de base de données pour tous les travaux et QRTZ_SIMPLE_TRIGGERS.REPEAT_INTERVAL est correct (60 000 millisecondes). La différence entre QRTZ_TRIGGERS.PREV_FIRE_TIME et QRTZ_TRIGGERS.NEXT_FIRE_TIME est également de 60 000.

Ma quartzProperties définition dans le fichier de contexte d'application comporte les entrées suivantes:

<property name="quartzProperties"> 
    <props> 
     <prop key="org.quartz.scheduler.instanceName">MyClusteredScheduler</prop> 
     <prop key="org.quartz.scheduler.instanceId">AUTO</prop> 
     <prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop> 
     <prop key="org.quartz.threadPool.threadCount">5</prop> 
     <prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop> 
     <prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.StdJDBCDelegate</prop> 
     <prop key="org.quartz.jobStore.isClustered">true</prop> 
     <prop key="org.quartz.jobStore.clusterCheckinInterval">5000</prop> 
     <prop key="org.quartz.jobStore.dataSource">myDS</prop> 
     <prop key="org.quartz.jobStore.tablePrefix">QRTZ_</prop> 
     <prop key="org.quartz.dataSource.myDS.driver">oracle.jdbc.driver.OracleDriver</prop> 
     <prop key="org.quartz.dataSource.myDS.URL">{db connection string}</prop> 
     <prop key="org.quartz.dataSource.myDS.user">{username}</prop> 
     <prop key="org.quartz.dataSource.myDS.password">{password}</prop> 
     <prop key="org.quartz.dataSource.myDS.maxConnections">5</prop> 
     <prop key="org.quartz.dataSource.myDS.validationQuery">select 0 from dual</prop> 
    </props> 
</property> 

Toute pensée sur pourquoi cela devrait être? Merci d'avance.

Answer 1

Apparemment résolu: le problème était plus lié à la dépendance aux messages de journalisation incohérents que de suggérer des temps de déclenchement incohérents que tout ce qui concerne Quartz.