Quartz & Spring - Clustered, но NOT Persistent?

В моем приложении Spring я использую SchedulerFactoryBean для интеграции с Quartz. У нас будут кластерные экземпляры Tomcat, и поэтому я хочу иметь кластерную среду Quartz, чтобы одни и те же задания не запускались одновременно на разных веб-серверах.

Для этого мой app-context.xml выглядит следующим образом:

<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>

Все работает хорошо, за исключением того, что когда я пытаюсь удалить или изменить триггер, перезагрузите приложение, старые триггеры все еще сохраняются в БД и все еще работают. Я не хочу этого, я просто хочу, чтобы их удаляли, когда приложение останавливается (или перезапускается). Я устанавливаю значение свойства overwriteExistingJobs как true, так как я думал, что он сделал.

Любые идеи? Все, что я хочу использовать для БД, это кластеризация, а не какая-либо настойчивость.

Ответ 1

Я проделал исследование по этой теме, и что известная ошибка в Quartz, я нашел несколько сообщений на их форуме. Чтобы решить эту проблему, я создал bean, который удаляет все записи в таблице кварца. Вы можете вызвать этот bean до того, как ваш Quartz bean будет загружен (добавьте "зависит от" в вашем планировщике bean), когда ваш контекст spring уничтожается (убедитесь, что пул соединений с БД все еще открыт ) или вручную через какой-либо пользовательский интерфейс. Там также ошибка в рабочих группах, не удивляйтесь. Моим первым решением было создать клиентскую банку Quartz с исправлением, но было довольно сложно обновиться, когда они выпустили новую версию (в то время я использовал 1.4 или 1.5) - на самом деле не помню).

Ответ 2

Я столкнулся с аналогичной проблемой с кластеризованным кварцем 2. Я не работал на верблюде, но это та же проблема.

1) Я не видел, чтобы удалить задания в кластерной среде, просто удалив задания/триггеры из контекста xml spring.

2) Поскольку база данных хранит информацию о задании/триггере, развертывание развертывания на серверах становится проблематичным, если вы добавляете или изменяете задания. Серверы могут запускать задания до того, как реализация задания может быть развернута на сервере приложений, если только вы не удалите все серверы до развертывания ваших изменений.

Чтобы решить эту проблему, я придумал довольно простое решение. В рамках нашего процесса сборки мы уже фиксировали и сохраняли уникальную версию сборки + число с артефактом сборки (с заменой переменных gradle). Чтобы решить эту проблему, мы просто указали, что имя планировщика включает уникальную версию сборки + номер. Это приводит к тому, что последний набор заданий + триггеры добавляются в db под новым именем планировщика, и после развертывания развертывания все серверы запускаются с новым именем. Это решает проблему удаления, а также решает проблему развертывания развертывания. Если все дополнительные имена планировщика становятся проблемой в db, что-то может быть записано для их очистки при необходимости.

Ответ 3

Это старый пост, но для тех, кто нуждается в решении, вот он. Укажите "true" для свойства "overwriteExistingJobs". Вам придется перезагрузить сервер, и каждый раз, когда вы перезагружаетесь, старые задания будут удалены. Я не знаю, было ли это возможно в более старых версиях кварцевого планировщика, я использую 2.1.7