Return-Path: 
 <camel-dev-return-8023-apmail-activemq-camel-dev-archive=activemq.apache.org@activemq.apache.org>
Delivered-To: apmail-activemq-camel-dev-archive@locus.apache.org
Received: (qmail 40103 invoked from network); 11 Dec 2008 17:37:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 11 Dec 2008 17:37:29 -0000
Received: (qmail 11886 invoked by uid 500); 11 Dec 2008 17:37:42 -0000
Delivered-To: apmail-activemq-camel-dev-archive@activemq.apache.org
Received: (qmail 11860 invoked by uid 500); 11 Dec 2008 17:37:41 -0000
Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:camel-dev-help@activemq.apache.org>
List-Unsubscribe: <mailto:camel-dev-unsubscribe@activemq.apache.org>
List-Post: <mailto:camel-dev@activemq.apache.org>
List-Id: <camel-dev.activemq.apache.org>
Reply-To: camel-dev@activemq.apache.org
Delivered-To: mailing list camel-dev@activemq.apache.org
Received: (qmail 11836 invoked by uid 99); 11 Dec 2008 17:37:41 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Dec 2008 09:37:41 -0800
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Dec 2008 17:37:26 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 8757A234C382
	for <camel-dev@activemq.apache.org>; Thu, 11 Dec 2008 09:37:05 -0800 (PST)
Message-ID: <680348501.1229017025553.JavaMail.jira@brutus>
Date: Thu, 11 Dec 2008 09:37:05 -0800 (PST)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Updated: (CAMEL-1185) Message-triggered scheduling (producer
 for camel-quartz)
In-Reply-To: <649891823.1229013545392.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on 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&amp;trigger.repeatInterval=10000&amp;dynamic=true" />
> </route>
> <route>
>     <!-- Create consumer -->
>     <from uri="quartz://requests?trigger.repeatCount=3&amp;trigger.repeatInterval=10000&amp;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.