[
https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Turpitko updated CAMEL-7627:
------------------------------------
Description:
When quartz/quartz2 component used in cluster mode with JDBCJobStore it gets
trigger settings (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 settings 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.
was:
When quartz/quartz2 component used in cluster mode with JDBCJobStore it stores
trigger settings (cron expression or simple trigger repeat interval and repeat
count) provided in component's URI in DB. When application 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 new version of 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 settings in DB and reschedule quartz job
when they changed.
I created a patch with unit test to illustrate this issue. 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.
> 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-quartz.patch
>
>
> When quartz/quartz2 component used in cluster mode with JDBCJobStore it gets
> trigger settings (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 settings 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
