You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Hadrian Zbarcea (JIRA)" <ji...@apache.org> on 2009/01/27 19:01:02 UTC
[jira] Commented: (CAMEL-1002) Quartz support should allow stateful
jobs
[ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48974#action_48974 ]
Hadrian Zbarcea commented on CAMEL-1002:
----------------------------------------
Patch applied with thanks to Martin on both trunk and camel-1.x branch.
> 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.