I would use option [1], using probably quartz instead of timer.

Hadrian

On Apr 4, 2011, at 11:09 AM, Paul Lowry wrote:

> Hi,
> 
> I am using Camel 2.4.0 to define routes in XML (Spring configuration
> files). I want my route to read all messages from a JMS queue, at
> regular intervals. I also want to keep my route as simple as possible,
> for easy maintenance.
> 
> When I look for info about this, there's lots of advice but nothing
> definitive. Included below are paraphrased versions of the info I found.
> 
> Please advise on which approach is the simplest and/or most reliable.
> 
> Thanks,
> Paul
> 
> [1]
> 
> Approach #1: a timer consumer, then a pollEnrich processor to
> pull in a JMS message.
> 
> Example:
> <route id="RetryTimerRoute">
>  <from uri="timer://myTimer?period=3600000"/>
>  <pollEnrich uri="activemq:queue:MyQueue"/>
>  ...
> </route>
> 
> Note:
> It might be necessary to set the pre-fetch value for the JMS connection
> to zero, i.e. "activemq:queue:MyQueue?consumer.prefetchSize=0"
> 
> References:
> http://camel.apache.org/content-enricher.html
> http://camel.apache.org/polling-consumer.html
> http://activemq.apache.org/destination-options.html
> http://activemq.apache.org/what-is-the-prefetch-limit-for.html
> 
> [2]
> 
> Approach #2: use templates to move messages onto another
> queue at regular intervals; then let consumer of that queue process all
> messages.
> 
> Example:
> public static class MyRetryTimer {
>  private ConsumerTemplate consumer;
>  private ProducerTemplate producer;
>  public void setConsumer(ConsumerTemplate consumer) {
>    this.consumer = consumer;
>  }
>  public void setProducer(ProducerTemplate producer) {
>    this.producer = producer;
>  }
>  public void transferMessagesForRetry() {
>    // move all messages
>    while (true) {
>      String msg = consumer.receive("activemq:queue:MyFirstQueue",
> 1000);
>      if (msg == null) {
>        // no more messages
>        break;
>      }
>      producer.send("activemq:queue:MySecondQueue", msg);
>    }
>  }
> }
> <bean id="RetryTimer" class="MyRetryTimer"/>
> <route id="RetryTimerRoute">
>  <from uri="timer://myTimer?period=3600000"/>
>  <to uri="bean:RetryTimer?method=transferMessagesForRetry"/>
> </route>
> <route id="RetryRoute">
>  <from uri="activemq:queue:MySecondQueue"/>
>  ...
> </route>
> 
> Notes:
> How do I inject the consumer & producer?
> 
> References:
> http://camel.apache.org/polling-consumer.html
> http://fusesource.com/docs/router/2.6/prog_guide/Templates-Consumer.html
> 
> [3]
> 
> Approach #3: define a task executor in spring, and use it to set the
> consumer's "taskExecutor" option. This is not well documented.
> 
> Example:
> <bean class="org.springframework.core.task.TimerTaskExecutor">
>  <!-- some config goes here -->
> </bean>
> <route id="RetryRoute">
>  <from
> uri="activemq:queue:MyQueue?taskExecutor=org.springframework.core.task.TimerTaskExecutor"/>
>  ...
> </route>
> 
> Notes:
> Is the example correct? How do I configure the spring task executor?
> 
> References:
> http://camel.apache.org/jms
> http://static.springsource.org/spring/docs/2.5.6/reference/scheduling.html
> https://issues.apache.org/jira/browse/CAMEL-3286
> 
> --
> 
> EOF
> 
> STRICTLY PRIVATE, CONFIDENTIAL AND PRIVILEGED COMMUNICATION.
> 
> This message (including attachments) may contain information that is
> privileged, confidential or protected from disclosure. They are intended
> solely for the use of the intended recipient. If you are not the
> intended recipient, you are hereby notified that dissemination,
> disclosure, copying, distribution, printing, transmission or use of this
> message or any information contained in it is strictly prohibited. If
> you have received this message from NewBay Software in error, please
> immediately notify the sender by reply email and delete this message
> from your computer. The content of this e-mail, and any files
> transmitted with it, may have been changed or altered without the
> consent of the author. Although we have taken steps to ensure that this
> email and attachments are free from any virus, we advise that in keeping
> with good computing practice the recipient should ensure they are
> actually virus free.

Reply via email to