You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Ivan S. Dubrov (JIRA)" <ji...@apache.org> on 2008/12/11 17:39:05 UTC
[jira] Created: (CAMEL-1185) Message-triggered scheduling (producer
for camel-quartz)
Message-triggered scheduling (producer for camel-quartz)
--------------------------------------------------------
Key: CAMEL-1185
URL: https://issues.apache.org/activemq/browse/CAMEL-1185
Project: Apache Camel
Issue Type: Improvement
Components: camel-quartz
Affects Versions: 1.5.1, 2.0.0
Reporter: Ivan S. Dubrov
I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
For example:
<route>
...
<setHeader headerName="startTime">
<!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
<xpath>/notification/@time</xpath>
</setHeader>
<!--
Create trigger with repeat count to 3 and interval of 10 seconds.
The start time is retrieved from the header
-->
<to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
</route>
<route>
<!-- Create consumer -->
<from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
...
</route>
So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
The patch is provided. However, it has several drawbacks:
1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1185) Message-triggered scheduling
(producer for camel-quartz)
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48122#action_48122 ]
Claus Ibsen commented on CAMEL-1185:
------------------------------------
Ivan nice patch at first glance.
Do you mind supplying some unit tests as well?
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1185) Message-triggered scheduling (producer
for camel-quartz)
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1185:
-------------------------------
Fix Version/s: 2.1.0
We should have improved scheduling in Camel 2.1 also with quartz
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-quartz
> Affects Versions: 1.6.0, 2.0.0
> Reporter: Ivan S. Dubrov
> Fix For: 2.1.0
>
> Attachments: quartz-triggered.patch, quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1185) Message-triggered scheduling
(producer for camel-quartz)
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48123#action_48123 ]
Claus Ibsen commented on CAMEL-1185:
------------------------------------
I think James Strachan created a ticket for some related idea of being able to send a timer message to quartz when it should fire.
So you might find his ticket in JIRA and see if his idea is covered by your patch?
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1185) Message-triggered scheduling (producer
for camel-quartz)
Posted by "Ivan S. Dubrov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan S. Dubrov updated CAMEL-1185:
----------------------------------
Attachment: quartz-triggered.patch
Patch which enables the described functionality.
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1185) Message-triggered scheduling
(producer for camel-quartz)
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50482#action_50482 ]
Claus Ibsen commented on CAMEL-1185:
------------------------------------
Ivan do you mind looking if the patch still appies to the trunk code?
I remember we have recently added some other patches to quartz.
Your idea is good and lets see if we can get it into 2.0.
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-quartz
> Affects Versions: 1.6.0, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch, quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1185) Message-triggered scheduling (producer
for camel-quartz)
Posted by "Ivan S. Dubrov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan S. Dubrov updated CAMEL-1185:
----------------------------------
Attachment: quartz-triggered.patch
Attached patch with unit tests.
Looking at the linked issue, I think of different approach to producer implementation. Instead of requiring the consumer with exactly the same endpoint URI (as in my implementation), it is probably better to specify the target endpoint URI in the producer endpoint URI parameter.
Instead of two routes:
from("direct:start").setHeader("startTime", constant(startTime)).to("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1&dynamic=true");
and
from("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1&dynamic=true").to("mock:result");
that could be like:
from("direct:start").setHeader("startTime", constant(startTime)).to("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1&target=mock:results");
The advantage is that if Quartz is in clustered mode, the former approach will require having the consumer declared on each node Quartz is running on. The latter approach is more flexible (you can specify, for example, "jms:somequeue" which will work on every node, requiring only minimal JMS configuration).
What do you think?
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch, quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1185) Message-triggered scheduling (producer
for camel-quartz)
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1185:
-------------------------------
Issue Type: New Feature (was: Improvement)
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CAMEL-1185) Message-triggered
scheduling (producer for camel-quartz)
Posted by "Ivan S. Dubrov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48140#action_48140 ]
wfrag edited comment on CAMEL-1185 at 12/11/08 9:01 PM:
-----------------------------------------------------------------
Added link to the similar feature issue
was (Author: wfrag):
Similar issue
> Message-triggered scheduling (producer for camel-quartz)
> --------------------------------------------------------
>
> Key: CAMEL-1185
> URL: https://issues.apache.org/activemq/browse/CAMEL-1185
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-quartz
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Ivan S. Dubrov
> Attachments: quartz-triggered.patch
>
>
> I suggest implementing the producer for the Quartz component that will enable scheduling the message delivery driven by the incoming messages.
> The idea is that instead of creating trigger when consumer is created, create trigger when message is sent to the endpoint, taking additional trigger parameters from the headers.
> For example:
> <route>
> ...
> <setHeader headerName="startTime">
> <!-- Assume the XPath returns java.util.Date (actually, extra converter is required) -->
> <xpath>/notification/@time</xpath>
> </setHeader>
> <!--
> Create trigger with repeat count to 3 and interval of 10 seconds.
> The start time is retrieved from the header
> -->
> <to uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> </route>
> <route>
> <!-- Create consumer -->
> <from uri="quartz://requests?trigger.repeatCount=3&trigger.repeatInterval=10000&dynamic=true" />
> ...
> </route>
> So, if we have <notification time="2008-12-11T22:06:00Z">...Notification data...</notification> sent to the endpoint in the first route, the trigger will be created targeted at time specified in the "time" attribute. When Quartz will fire the trigger, the message will be sent in the second route.
> It could be used as a kind of "delayer", but more flexible and featureful. For example, for delaying messages for a long time (week, days, etc), when resequencer+delayer will not work (as far as I understand).
> The patch is provided. However, it has several drawbacks:
> 1) in "dynamic" mode (when scheduling is triggered by incoming messages) group/name parsed from the endpoint URI is not used, trigger and job receive name from the exchange id
> 2) The consumer/producer part of the URI must be exactly equal (because the consumer/producer must be created exactly by the same endpoint).
> 3) It will not work when Quartz is clustered (the endpoint URI should be stored instead of endpoint reference, see CAMEL-1002 which fixes this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.