[
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.
