[
https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47761#action_47761 ]
Martin Gilday commented on CAMEL-1002:
--------------------------------------
Not at all Hadrian. I would love to see this in 1.5.1 as it is something we need to use fairly soon, but I have not had time to start the patch.
I would take a look at my comments above about "Current Faults". Refactoring my existing patch so that both stateful and non-stateful jobs use my new way of locating the endpoint will prevent having to maintain two ways of doing the same thing in the future.
The only other thing I have thought of is writing a test to show that quartz.properties is loaded correctly so that JDBC job stores and clustering can be configured.
If you get it into the trunk then I am more than happy to help write some tests and document it on the wiki when I start using it.
Thanks for your help.
> 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
> 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.
Locked
