You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Martin Gilday <ma...@imap.cc> on 2008/10/20 13:53:26 UTC
Clustered Quartz
Hi riders,
Has anyone attempted to use the Quartz component in a "clustered" Quartz
setup i.e with a JDBC job store?
I am looking at a situation where I would have items placed in a DB
table and I would like to do the following:
from quartz to jdbc to processor to jms to processor
However my Camel routes will be running on more than one machine. As
the processing of the JDBC result can on some occasions take longer than
the trigger length the trigger should not fire if the job is still
running. This works easily in our non-Camel Spring and Quartz setup.
All you need is a quartz.properties and a shared JDBC job store.
I have looked at the camel-quartz source and I do not think what I am
after is currently possible. As CamelJob implements Job and not
StatefulJob then it is impossible to create a blocking job. The other
issue is that the endpoint is placed into the JobDataMap, which I think
may not be compatible with the JDBC job store (I don't think the
endpoint would serialise).
I think we could update the component with a parameter such as
"blocking"; create a subclass of CamelJob called BlockingCamelJob which
implements StatefulJob (the implementation need not change as it is only
a marker interface); if blocking=true then create a BlockingCamelJob
instead of CamelJob. The only remaining problem would be whether the
JobDataMap would persist.
Can anyone think of an easy alternative to this that would achieve what
I am after?
Martin
Re: Clustered Quartz
Posted by Martin Gilday <ma...@imap.cc>.
No problem Claus.
----- Original message -----
From: "Claus Ibsen" <cl...@gmail.com>
To: camel-user@activemq.apache.org
Date: Wed, 26 Nov 2008 10:37:01 +0100
Subject: Re: Clustered Quartz
Hi Martin
We could get this up to speed if you could assist with
1) Creating a new patch from the 2.0 trunk as we have removed generics
2) update or (write what is needed) for the wiki documentation on this
new feature for camel-quartz at:
http://activemq.apache.org/camel/quartz.html
Then I am sure we will be able to get it into the trunk pretty soon.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 26, 2008 at 10:25 AM, Martin Gilday <ma...@imap.cc>
wrote:
> Have any committers had a chance to look at CAMEL-1002? We are looking
> to use Camel Quartz and it would be very useful to be able to do this,
> even if it is just in a snapshot.
>
> Thanks,
> Martin.
>
> ----- Original message -----
> From: "Martin Gilday" <ma...@imap.cc>
> To: camel-user@activemq.apache.org
> Date: Tue, 21 Oct 2008 10:03:12 +0100
> Subject: RE: Clustered Quartz
>
> Created http://issues.apache.org/activemq/browse/CAMEL-1002 and attached
> a draft patch.
>
>
> ----- Original message -----
> From: "Claus Ibsen" <ci...@silverbullet.dk>
> To: camel-user@activemq.apache.org
> Date: Mon, 20 Oct 2008 14:03:21 +0200
> Subject: RE: Clustered Quartz
>
> Hi
>
> Why not use the name StatefulCamelJob as Quartz uses Stateful for this
> kind of name?
>
> Yes we love contributions as you know so please create a ticket for this
> great feature.
>
> Yeah the endpoint etc. is not serializable but the endpoint URI is, so
> it could be persisted and used to lookup the endpoint upon retrieval.
> From the camel context you can lookup endpoints by its uri.
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Martin Gilday [mailto:martin.lists@imap.cc]
> Sent: 20. oktober 2008 13:53
> To: camel-user@activemq.apache.org
> Subject: Clustered Quartz
>
> Hi riders,
>
> Has anyone attempted to use the Quartz component in a "clustered" Quartz
> setup i.e with a JDBC job store?
>
> I am looking at a situation where I would have items placed in a DB
> table and I would like to do the following:
> from quartz to jdbc to processor to jms to processor
>
> However my Camel routes will be running on more than one machine. As
> the processing of the JDBC result can on some occasions take longer than
> the trigger length the trigger should not fire if the job is still
> running. This works easily in our non-Camel Spring and Quartz setup.
> All you need is a quartz.properties and a shared JDBC job store.
>
> I have looked at the camel-quartz source and I do not think what I am
> after is currently possible. As CamelJob implements Job and not
> StatefulJob then it is impossible to create a blocking job. The other
> issue is that the endpoint is placed into the JobDataMap, which I think
> may not be compatible with the JDBC job store (I don't think the
> endpoint would serialise).
>
> I think we could update the component with a parameter such as
> "blocking"; create a subclass of CamelJob called BlockingCamelJob which
> implements StatefulJob (the implementation need not change as it is only
> a marker interface); if blocking=true then create a BlockingCamelJob
> instead of CamelJob. The only remaining problem would be whether the
> JobDataMap would persist.
>
> Can anyone think of an easy alternative to this that would achieve what
> I am after?
>
> Martin
>
Re: Clustered Quartz
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Martin
We could get this up to speed if you could assist with
1) Creating a new patch from the 2.0 trunk as we have removed generics
2) update or (write what is needed) for the wiki documentation on this
new feature for camel-quartz at:
http://activemq.apache.org/camel/quartz.html
Then I am sure we will be able to get it into the trunk pretty soon.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 26, 2008 at 10:25 AM, Martin Gilday <ma...@imap.cc> wrote:
> Have any committers had a chance to look at CAMEL-1002? We are looking
> to use Camel Quartz and it would be very useful to be able to do this,
> even if it is just in a snapshot.
>
> Thanks,
> Martin.
>
> ----- Original message -----
> From: "Martin Gilday" <ma...@imap.cc>
> To: camel-user@activemq.apache.org
> Date: Tue, 21 Oct 2008 10:03:12 +0100
> Subject: RE: Clustered Quartz
>
> Created http://issues.apache.org/activemq/browse/CAMEL-1002 and attached
> a draft patch.
>
>
> ----- Original message -----
> From: "Claus Ibsen" <ci...@silverbullet.dk>
> To: camel-user@activemq.apache.org
> Date: Mon, 20 Oct 2008 14:03:21 +0200
> Subject: RE: Clustered Quartz
>
> Hi
>
> Why not use the name StatefulCamelJob as Quartz uses Stateful for this
> kind of name?
>
> Yes we love contributions as you know so please create a ticket for this
> great feature.
>
> Yeah the endpoint etc. is not serializable but the endpoint URI is, so
> it could be persisted and used to lookup the endpoint upon retrieval.
> From the camel context you can lookup endpoints by its uri.
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Martin Gilday [mailto:martin.lists@imap.cc]
> Sent: 20. oktober 2008 13:53
> To: camel-user@activemq.apache.org
> Subject: Clustered Quartz
>
> Hi riders,
>
> Has anyone attempted to use the Quartz component in a "clustered" Quartz
> setup i.e with a JDBC job store?
>
> I am looking at a situation where I would have items placed in a DB
> table and I would like to do the following:
> from quartz to jdbc to processor to jms to processor
>
> However my Camel routes will be running on more than one machine. As
> the processing of the JDBC result can on some occasions take longer than
> the trigger length the trigger should not fire if the job is still
> running. This works easily in our non-Camel Spring and Quartz setup.
> All you need is a quartz.properties and a shared JDBC job store.
>
> I have looked at the camel-quartz source and I do not think what I am
> after is currently possible. As CamelJob implements Job and not
> StatefulJob then it is impossible to create a blocking job. The other
> issue is that the endpoint is placed into the JobDataMap, which I think
> may not be compatible with the JDBC job store (I don't think the
> endpoint would serialise).
>
> I think we could update the component with a parameter such as
> "blocking"; create a subclass of CamelJob called BlockingCamelJob which
> implements StatefulJob (the implementation need not change as it is only
> a marker interface); if blocking=true then create a BlockingCamelJob
> instead of CamelJob. The only remaining problem would be whether the
> JobDataMap would persist.
>
> Can anyone think of an easy alternative to this that would achieve what
> I am after?
>
> Martin
>
RE: Clustered Quartz
Posted by Martin Gilday <ma...@imap.cc>.
Have any committers had a chance to look at CAMEL-1002? We are looking
to use Camel Quartz and it would be very useful to be able to do this,
even if it is just in a snapshot.
Thanks,
Martin.
----- Original message -----
From: "Martin Gilday" <ma...@imap.cc>
To: camel-user@activemq.apache.org
Date: Tue, 21 Oct 2008 10:03:12 +0100
Subject: RE: Clustered Quartz
Created http://issues.apache.org/activemq/browse/CAMEL-1002 and attached
a draft patch.
----- Original message -----
From: "Claus Ibsen" <ci...@silverbullet.dk>
To: camel-user@activemq.apache.org
Date: Mon, 20 Oct 2008 14:03:21 +0200
Subject: RE: Clustered Quartz
Hi
Why not use the name StatefulCamelJob as Quartz uses Stateful for this
kind of name?
Yes we love contributions as you know so please create a ticket for this
great feature.
Yeah the endpoint etc. is not serializable but the endpoint URI is, so
it could be persisted and used to lookup the endpoint upon retrieval.
>From the camel context you can lookup endpoints by its uri.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc]
Sent: 20. oktober 2008 13:53
To: camel-user@activemq.apache.org
Subject: Clustered Quartz
Hi riders,
Has anyone attempted to use the Quartz component in a "clustered" Quartz
setup i.e with a JDBC job store?
I am looking at a situation where I would have items placed in a DB
table and I would like to do the following:
from quartz to jdbc to processor to jms to processor
However my Camel routes will be running on more than one machine. As
the processing of the JDBC result can on some occasions take longer than
the trigger length the trigger should not fire if the job is still
running. This works easily in our non-Camel Spring and Quartz setup.
All you need is a quartz.properties and a shared JDBC job store.
I have looked at the camel-quartz source and I do not think what I am
after is currently possible. As CamelJob implements Job and not
StatefulJob then it is impossible to create a blocking job. The other
issue is that the endpoint is placed into the JobDataMap, which I think
may not be compatible with the JDBC job store (I don't think the
endpoint would serialise).
I think we could update the component with a parameter such as
"blocking"; create a subclass of CamelJob called BlockingCamelJob which
implements StatefulJob (the implementation need not change as it is only
a marker interface); if blocking=true then create a BlockingCamelJob
instead of CamelJob. The only remaining problem would be whether the
JobDataMap would persist.
Can anyone think of an easy alternative to this that would achieve what
I am after?
Martin
RE: Clustered Quartz
Posted by Martin Gilday <ma...@imap.cc>.
Created http://issues.apache.org/activemq/browse/CAMEL-1002 and attached
a draft patch.
----- Original message -----
From: "Claus Ibsen" <ci...@silverbullet.dk>
To: camel-user@activemq.apache.org
Date: Mon, 20 Oct 2008 14:03:21 +0200
Subject: RE: Clustered Quartz
Hi
Why not use the name StatefulCamelJob as Quartz uses Stateful for this
kind of name?
Yes we love contributions as you know so please create a ticket for this
great feature.
Yeah the endpoint etc. is not serializable but the endpoint URI is, so
it could be persisted and used to lookup the endpoint upon retrieval.
>From the camel context you can lookup endpoints by its uri.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc]
Sent: 20. oktober 2008 13:53
To: camel-user@activemq.apache.org
Subject: Clustered Quartz
Hi riders,
Has anyone attempted to use the Quartz component in a "clustered" Quartz
setup i.e with a JDBC job store?
I am looking at a situation where I would have items placed in a DB
table and I would like to do the following:
from quartz to jdbc to processor to jms to processor
However my Camel routes will be running on more than one machine. As
the processing of the JDBC result can on some occasions take longer than
the trigger length the trigger should not fire if the job is still
running. This works easily in our non-Camel Spring and Quartz setup.
All you need is a quartz.properties and a shared JDBC job store.
I have looked at the camel-quartz source and I do not think what I am
after is currently possible. As CamelJob implements Job and not
StatefulJob then it is impossible to create a blocking job. The other
issue is that the endpoint is placed into the JobDataMap, which I think
may not be compatible with the JDBC job store (I don't think the
endpoint would serialise).
I think we could update the component with a parameter such as
"blocking"; create a subclass of CamelJob called BlockingCamelJob which
implements StatefulJob (the implementation need not change as it is only
a marker interface); if blocking=true then create a BlockingCamelJob
instead of CamelJob. The only remaining problem would be whether the
JobDataMap would persist.
Can anyone think of an easy alternative to this that would achieve what
I am after?
Martin
RE: Clustered Quartz
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
Why not use the name StatefulCamelJob as Quartz uses Stateful for this kind of name?
Yes we love contributions as you know so please create a ticket for this great feature.
Yeah the endpoint etc. is not serializable but the endpoint URI is, so it could be persisted and used to lookup the endpoint upon retrieval. >From the camel context you can lookup endpoints by its uri.
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc]
Sent: 20. oktober 2008 13:53
To: camel-user@activemq.apache.org
Subject: Clustered Quartz
Hi riders,
Has anyone attempted to use the Quartz component in a "clustered" Quartz
setup i.e with a JDBC job store?
I am looking at a situation where I would have items placed in a DB
table and I would like to do the following:
from quartz to jdbc to processor to jms to processor
However my Camel routes will be running on more than one machine. As
the processing of the JDBC result can on some occasions take longer than
the trigger length the trigger should not fire if the job is still
running. This works easily in our non-Camel Spring and Quartz setup.
All you need is a quartz.properties and a shared JDBC job store.
I have looked at the camel-quartz source and I do not think what I am
after is currently possible. As CamelJob implements Job and not
StatefulJob then it is impossible to create a blocking job. The other
issue is that the endpoint is placed into the JobDataMap, which I think
may not be compatible with the JDBC job store (I don't think the
endpoint would serialise).
I think we could update the component with a parameter such as
"blocking"; create a subclass of CamelJob called BlockingCamelJob which
implements StatefulJob (the implementation need not change as it is only
a marker interface); if blocking=true then create a BlockingCamelJob
instead of CamelJob. The only remaining problem would be whether the
JobDataMap would persist.
Can anyone think of an easy alternative to this that would achieve what
I am after?
Martin