[jira] Resolved: (CAMEL-1002) Quartz support should allow stateful jobs

["Hadrian Zbarcea (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hadrian Zbarcea resolved CAMEL-1002.
------------------------------------

    Resolution: Fixed

> Quartz support should allow stateful jobs
> -----------------------------------------
>
>                 Key: CAMEL-1002
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1002
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-quartz
>    Affects Versions: 1.4.0
>            Reporter: Martin Gilday
>            Assignee: Hadrian Zbarcea
>             Fix For: 1.5.1, 2.0.0
>
>         Attachments: quartz.patch
>
>
> See http://www.nabble.com/Clustered-Quartz-td20068086s22882.html
> Currently Quartz only has CamelJob which implements Quartz's Job interface.  There is no option to use an implemenation of StatefulJob.  This causes problems when you may want to use a JDBC JobStore and have Quartz running on multiple machines, as you may end up with multiple jobs running together.  StatefulJob in effect allows for a blocking singleton style job on one machine.
> Attached is a patch which adds a new URI parameter named "stateful", which defaults to false.  When set to true it uses StatefulCamelJob.
> One significant change to the QuartzComponent is that a reference to the CamelContext is now stored in the Quartz Scheduler.  This idea is taken from Spring's SchedulerFactoryBean which stores a reference to a Spring ApplicationContext.  This is needed as when using stateful jobs the URI of the Endpoint is stored instead of a reference to the endpoint.  This is to allow for the use of JDBC JobStore as the URI can be serialised and shared beteen participating schedulers.
> Current Faults:
> Still has no notion of volatility
> Difference in operation between CamelJob and StatefulCamelJob is not strictly needed.   It may be less confusing if both versions simply store the URI instead of an endpoint reference.
> You need to use stateful if you want to use clustering at all due to the reason above.  This is mixing together clustering support and blocking functionality.
> In Camel 2 we may want to try rewriting this Component as it is becoming a little messy.  It would be nice to try and harness the power of Spring's SchedulerFactoryBean.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.