camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <>
Subject Re: Missing feature to handle errors in a route which reads from an activemq destination
Date Thu, 23 Jun 2011 11:36:10 GMT
Hello guys and thank you for your answers/opinions!

Sorry for my late reply, but I was busy with some other tasks. But I didn't
forgot you... ;-)

@Ben: Looks like we share the same thoughts. I think your suggestion is
really simple (I like simple solutions) and works for most of our
requirements. But I also see some improvements with my suggested solution:
- I would like to have the ability of an exponential back of delay per
message (make the first retry after a few secons, the second after one
minute, ...). One of our services has a really high throughput and we have
to process the messages as early as possible when the back end system is
available again.
- If we use this pattern in multiple services, I think it's a good idea to
generalize this and make it available without the need of the error route
duplication for each route which has this requirement.

@Willem: If I understood you correct, you suggest something like this:
<bean id="activemq1"
  <property name="connectionFactory" ref="connectionFactory1" />

<bean id="connectionFactory1"
  <!-- some other properties -->

<bean id="activemq2"
  <property name="connectionFactory" ref="connectionFactory2" />

<bean id="connectionFactory2"
  <!-- some other properties -->

from(activemq1:queue:foo) // configured this ActiveMQConnectionFactory to

from(activemq2:queue:bar) // configured this ActiveMQConnectionFactory to

What I dislike on this solution is, that we have to create a separate
ActiveMQConnectionFactory for each service which use a different redelivery
policy. At present, we use an OSGI lookup in SMX to get the
ActiveMQConnectionFactory which is exported by SMX (from
activemq-broker.xml). I think this is more resource friendly...
But I will take this into account as a good alternative until we have a
solution like the one I suggested... :-)

@Charles: I hope we will find the time to discuss this in 3.5 weeks, if you
are here in Frankfurt with us - or two weeks before if you plan to attend
the FUSE Community day in Frankfurt...
If I understood you correct, you suggest the following:
public void configure() throws Exception {
    RedeliveryPolicy redeliveryPolicy = new RedeliveryPolicy();

    TransactionErrorHandlerBuilder errorHandlerBuilder = new


I'm not sure I understood how the TransactionErrorHandler works exactly. If
we configure the redeliveryDelay (and all the other options), what happens
under the cover? Does the TransactionErrorHandler waits this time until it
propagates the exception to the TransactionManager? If this is the case, I
have the same bad feelings as in the "normal" RedeliveryErrorHandler I
explained in my first post.

So I still think the new "delay and schedule message delivery" [1] from
ActiveMQ 5.4 brings a good feature we should support in Camel. I will work
out a simple example which hopefully convince you. ;-)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message