Cuarzo y primavera: ¿agrupado pero NO persistente?

Question

En mi aplicación Spring estoy usando el SchedulerFactoryBean para integrar con Quartz. Vamos a tener instancias agrupadas de Tomcat, y por lo tanto quiero tener un entorno de Cuarzo agrupado, de modo que los mismos trabajos no se ejecuten al mismo tiempo en diferentes servidores web.

Para hacer esto, mi app-context.xml es el siguiente:

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"> 
    <property name="triggers"> 
     <list> 
      <ref bean="cronTrigger"/> 
      <ref bean="simpleTrigger" /> 
     </list> 
    </property> 
    <property name="dataSource" ref="dataSource"/> 
    <property name="overwriteExistingJobs" value="true"/> 
    <!-- found in applicationContext-data.xml --> 
    <property name="applicationContextSchedulerContextKey" value="applicationContext"/> 
    <property name="quartzProperties"> 
     <props> 
      <prop key="org.quartz.scheduler.instanceName">SomeBatchScheduler</prop> 
      <prop key="org.quartz.scheduler.instanceId">AUTO</prop> 
      <prop key="org.quartz.jobStore.misfireThreshold">60000</prop> 
      <!--<prop key="org.quartz.jobStore.class">org.quartz.simpl.RAMJobStore</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.tablePrefix">QRTZ_</prop> 
      <prop key="org.quartz.jobStore.isClustered">true</prop> 
      <prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop> 
      <prop key="org.quartz.threadPool.threadCount">25</prop> 
      <prop key="org.quartz.threadPool.threadPriority">5</prop> 
     </props> 
    </property> 
</bean> 

Todo funciona bien, excepto que cuando intento de quitar o cambiar un disparador, a continuación, reinicie mi aplicación, los viejos disparadores son todavía persistían en el DB, y todavía se ejecuta. No quiero esto, solo quiero que se eliminen cuando la aplicación se detiene (o se reinicia). Establecí el valor de la propiedad overwriteExistingJobs como verdadero, ya que pensé que eso era lo que hacía.

¿Alguna idea? Todo lo que quiero usar para la base de datos es la agrupación, no cualquier tipo de persistencia más allá de eso.

Answer 1

He hecho investigaciones sobre el tema y ese es un error muy conocido en Quartz, encontré algunas publicaciones en su foro. Para resolver este problema, creé un bean que elimina todos los registros en la tabla de Quartz. Puede llamar a este bean antes de cargar su Bean Quartz (agregue un "depende de" en su bean Scheduler), cuando su contexto de primavera esté siendo destruido (asegúrese de que el grupo de conexiones DB todavía esté abierto), o manualmente a través de alguna forma UI. También hay un error en los grupos de trabajo, no se sorprenda. Mi primera solución fue crear un tarro de Quartz para el cliente con la solución, pero se hizo bastante difícil actualizar cada vez que lanzaron una nueva versión (yo estaba usando 1.4 o 1.5 en ese momento, realmente no recuerdo).

Answer 2

Esta es una publicación anterior, pero para el beneficio de aquellos que necesitan una solución, aquí está. Especifique "verdadero" para la propiedad "overwriteExistingJobs". Tendrá que reiniciar su servidor y cada vez que reinicie, se eliminarán los trabajos anteriores. No sé si esto fue posible en versiones anteriores de quartz-scheduler, estoy usando 2.1.7

Answer 3

Me encontré con un problema similar con cuarzo agrupado 2. No estaba ejecutando camello, pero es el mismo problema.

1) No hay manera de que haya visto eliminar los trabajos en un entorno agrupado simplemente eliminando los trabajos/desencadenadores del contexto de primavera xml.

2) Como la base de datos almacena el trabajo/desencadena la información, las implementaciones sucesivas en los servidores se vuelven problemáticas si agrega o modifica trabajos. Los servidores pueden comenzar a ejecutar trabajos antes de que la implementación del trabajo se pueda implementar en el servidor de la aplicación, a menos que eliminen todos los servidores antes de implementar los cambios.

Para resolver esto, se me ocurrió una solución bastante simple. Como parte de nuestro proceso de compilación, ya estábamos capturando y almacenando una versión de compilación única + número w/en el artefacto de construcción (utilizando la sustitución de variables gradle). Para resolver este problema, simplemente hicimos que el nombre del planificador incluyera la versión de compilación + número única. Esto da como resultado el último conjunto de trabajos + activadores que se agregan a la base de datos bajo el nombre del nuevo planificador, y una vez que finaliza la implementación continua, todos los servidores se ejecutan con el nuevo nombre. Esto resuelve el problema de eliminación y también resuelve el problema de despliegue continuo. Si todos los nombres adicionales del programador se convierten en un problema en el archivo db, se podría escribir algo para limpiarlos si es necesario.