Кварц и весна - сгруппированы, но НЕ постоянны?

Question

В моем приложении 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, так как думал, что это то, что он сделал.

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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