They are two different levels of granulartiy.
ActiveMQ redelivery is at the JMS client level. Camel redelivery mechanics
is at the processor level. Same with the DLQ.
Example: you have a route like this:
form("activemq:queue:foo").log("Incoming message: ${body}").to("mock:end")
What this means: your from("activemq:queue:foo") contains the JMS consumer.
ActiveMQ's redelivery will be applied there (will retry entire route).
If you set redelivery and DeadLetterChannel on the camel route, and for
example there was an error delivering to("mock:end") the camel retry
semantics will retry at to("mock:end"), not the entire route. If retries
are exhausted on the camel side, the DLChannel will be run. If redelivery
becomes exhausted at the consumer side, ActiveMQ will send a NACK back to
broker and broker will place into DeadLetterQueue.
On Mon, Oct 14, 2013 at 6:46 AM, Soelvar <jesper.s.karl...@gmail.com> wrote:
> Hi Claus,
>
> Thanks for the quick reply...I have read the chapter, which covers
> transactions well as you said. Still I am a bit unsure if there are any
> advantages from using activemq`s retry plugin over camels...it looks like
> camels retry supports roughly the same options. I guess given that my
> previous attempts to configure amq retry plugin has been cumbersome at
> best,
> I will probably try camels instead, unless there are some limitations that
> I
> am unaware of.
>
> Cheers,
> Jesper
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Transacted-processing-tp5741498p5741533.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
