Mechanizm kwarcowy i sprężynowy - klastrowany, ale nietrwały?

Question

W mojej aplikacji Spring używam SchedulerFactoryBean do integracji z Quartz. Będziemy mieć klastrowane instancje Tomcat, a więc chcę mieć klastrowane środowisko kwarcowe, aby te same zadania nie działały jednocześnie na różnych serwerach internetowych.

Aby to zrobić, mój app-context.xml jest następujący:

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

Wszystko działa dobrze, poza tym, że gdy próbuję usunąć lub zmienić spust, a następnie ponownie uruchomić aplikację, stare wyzwalacze są nadal utrzymywały się w DB, i nadal działa. Nie chcę tego, po prostu chcę je usunąć, gdy aplikacja zatrzyma się (lub zostanie ponownie uruchomiona). Ustawiłem wartość właściwości overwriteExistingJobs, aby była prawdziwa, ponieważ uważam, że tak właśnie było.

Wszelkie pomysły? Wszystko, co chcę użyć DB, to klastrowanie, a nie jakakolwiek trwałość poza tym.

Answer 1

Zrobiłem badania na ten temat i jest to dobrze znany błąd w Quartz, znalazłem kilka postów na ich forum. Aby rozwiązać ten problem, stworzyłem komponent bean, który usuwa wszystkie rekordy w tabeli kwarcowej. Możesz wywołać tę fasolę zanim Twój ziarno kwarcu zostanie załadowane (dodaj "zależne od" na twojej fasoli Scheduler), kiedy twój kontekst sprężyny jest niszczony (upewnij się, że pula połączeń DB jest nadal otwarta) lub ręcznie przez jakąś formę Interfejs użytkownika. Istnieje również błąd w grupach pracy, nie bądź zaskoczony. Moją pierwszą poprawką było stworzenie klienta kwarcu z naprawą, ale bardzo trudno było go uaktualnić za każdym razem, gdy wydali nową wersję (w tym czasie używałem wersji 1.4 lub 1.5 - tak naprawdę nie pamiętam).

Answer 2

To jest stary post, ale z korzyścią dla tych, którzy potrzebują rozwiązania, oto on. Podaj "true" dla właściwości "overwriteExistingJobs". Będziesz musiał ponownie uruchomić serwer i przy każdym uruchomieniu stare zadania zostaną usunięte. Nie wiem, czy było to możliwe w starszych wersjach kwarc-schedulera, używam 2.1.7

Answer 3

Wpadłem na podobny problem z zgrupowanym kwarcem 2. Nie pracowałem na wielbłądzie, ale to ten sam problem.

1) Nie widziałem możliwości usunięcia zadań w środowisku klastrowym poprzez usunięcie zadań/wyzwalaczy z kontekstowego kontekstu xml.

2) Ponieważ baza danych przechowuje informacje o zadaniu/wyzwalaczu, wdrażanie na wszystkich serwerach staje się problematyczne, jeśli dodajesz lub modyfikujesz zadania. Serwery mogą uruchamiać zadania, zanim wdrożenie zadania zostanie wdrożone na serwerze aplikacji, chyba że wszystkie serwery zostaną usunięte przed wdrożeniem zmian.

Aby rozwiązać ten problem, wymyśliłem całkiem proste rozwiązanie. W ramach naszego procesu budowania już przechwytywaliśmy i przechowywaliśmy unikalną wersję kompilacji + numer w/w artefakcie kompilacji (stosując zmienne zastępowanie zmienne). Aby rozwiązać ten problem, po prostu nazwa programu planującego zawiera unikalną wersję kompilacji + numer. Powoduje to dodanie do db do najnowszego zestawu zadań + wyzwalaczy pod nazwą nowego programu planującego, a po zakończeniu wdrażania stopniowania wszystkie serwery działają z nową nazwą. Rozwiązuje to problem usuwania, a także rozwiązuje problem z toczącym się wdrażaniem. Jeśli wszystkie dodatkowe nazwy terminarza staną się problemem w bazie danych, w razie potrzeby można by coś napisać, aby je wyczyścić.