[
https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Turpitko updated CAMEL-7627:
------------------------------------
Description:
Camel-quartz2 component in clustered mode uses trigger options stored in DB
rather (possibly changed) ones from endpoint's URI.
Desirable behavior is to compare trigger options in DB and endpoint's URI and
reschedule quartz job when they changed (like in camel-quartz component).
Component camel-quartz already have this functionality, but there is no test
for it and it works incorrectly with changed SimpleTrigger options.
I attached a patch with unit tests. Every test prepares DB, than creates
application context twice with different trigger options. Both times it
retrieves options back, accessing them via trigger (not via endpoint, so that
it uses values stored in DB). After that it asserts that retrieved options are
indeed different.
You can ensure, that the tests fail with old versions of
org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or
org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and
pass with patched implementation.
was:
When quartz/quartz2 component used in cluster mode with JDBCJobStore it gets
trigger options (cron expression or simple trigger repeat interval and repeat
count) provided in component's URI and stores them into DB.
When application runs next time, it uses stored values from DB and ignores
(possibly changed) ones from URI.
It is inconvenient in production environment to alter values in database every
time we deploy a new version of the application with changed schedule.
Especially, when we have bunch of clustered timers in several application
modules, using same DB. Desirable behavior is to check trigger options in DB
and reschedule quartz job when they changed.
I created a patch with unit test to illustrate this issue. The test prepares
DB, than creates application context twice with different cron expressions in
configuration xml. Both times it retrieves back the cron expression, accessing
it via trigger (so, using value stored in DB). After that it asserts that two
cron expressions are not equal.
You can check, that the test fails with old version of
org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler method and
passes with new one. Patched version of method compares existing trigger
options with new ones and reschedule job if they changed.
Component camel-quartz already have similar functionality, but there is no test
for it and it works incorrectly with changed SimpleTrigger options.
> Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
> ---------------------------------------------------------------------
>
> Key: CAMEL-7627
> URL: https://issues.apache.org/jira/browse/CAMEL-7627
> Project: Camel
> Issue Type: Bug
> Components: camel-quartz, camel-quartz2
> Affects Versions: 2.13.2, 2.14.0
> Reporter: Nikolay Turpitko
> Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch
>
>
> Camel-quartz2 component in clustered mode uses trigger options stored in DB
> rather (possibly changed) ones from endpoint's URI.
> Desirable behavior is to compare trigger options in DB and endpoint's URI and
> reschedule quartz job when they changed (like in camel-quartz component).
> Component camel-quartz already have this functionality, but there is no test
> for it and it works incorrectly with changed SimpleTrigger options.
> I attached a patch with unit tests. Every test prepares DB, than creates
> application context twice with different trigger options. Both times it
> retrieves options back, accessing them via trigger (not via endpoint, so that
> it uses values stored in DB). After that it asserts that retrieved options
> are indeed different.
> You can ensure, that the tests fail with old versions of
> org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or
> org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods
> and pass with patched implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
