You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Martin Gilday (JIRA)" <ji...@apache.org> on 2008/10/20 18:13:52 UTC
[jira] Created: (CAMEL-1002) Quartz support should allow stateful
jobs
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
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.
[jira] Resolved: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "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.
[jira] Updated: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "Martin Gilday (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Gilday updated CAMEL-1002:
---------------------------------
Attachment: quartz.patch
> 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
> 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.
[jira] Commented: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47749#action_47749 ]
Hadrian Zbarcea commented on CAMEL-1002:
----------------------------------------
@Martin, do you mind if I take care of this? I think it would be good to have it in both 1.5.1 and 2.0.
> 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.
[jira] Assigned: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "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 reassigned CAMEL-1002:
--------------------------------------
Assignee: Hadrian Zbarcea
> 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.
[jira] Commented: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "Martin Gilday (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47625#action_47625 ]
Martin Gilday commented on CAMEL-1002:
--------------------------------------
Working on new patch for 2.0
> 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
> 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.
[jira] Updated: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "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 updated CAMEL-1002:
-----------------------------------
Fix Version/s: 2.0.0
1.5.1
> 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.
[jira] Commented: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CAMEL-1002) Quartz support should allow stateful
jobs
Posted by "Martin Gilday (JIRA)" <ji...@apache.org>.
[ 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.