camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolay Turpitko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
Date Wed, 23 Jul 2014 10:49:38 GMT

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

So far I only created test for changed cron expression and quartz2 component.

  was:
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.

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 settings
with new ones and reschedule job if they changed.

So far I only created test for changed cron expression and quartz2 component.


> 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
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.
> So far I only created test for changed cron expression and quartz2 component.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message