camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <>
Subject Re: Advice needed with Camel/AMQ use case
Date Wed, 04 Apr 2012 12:56:47 GMT
Hi there,

This certainly seems like an interesting use case. Before I come forth with
an idea, could you please clarify what you mean with "create 1 queue per
destination and consume from all queues using a
wildcard. But I don't see a way of accomplishing everything without
having again
500 threads." - I don't see how having 500 threads could guarantee the
Quality of Service requirements you have anyway... I'm sure I'm missing

Besides that, have you thought about a multiplex-like pattern? If you can
drop the explicit message scheduling that you do, and rely on JMS
transactions with a correctly configured RedeliveryPolicy to match your
requirements, you could implement the following solution:

   - <route1> "the decomposer" => consume from dispatchHttpQueue and
   de-multiplex into the 500 queues depending on the final destination. Queue
   name pattern: "prefix.destination.<destinationId>". Compute this
   destination dynamically using recipient list, routing slip or dynamic
   - <route2> "the dispatcher" => consume from prefix.destination.* using
   local JMS transactions. Have as many threads as you want. No threads
   dedicated to specific destinations are needed. If an Exception occurs,
   Camel will rollback the JMS transaction and the redelivery policy will kick
   in. If you have a sequence of messages A, B, C, D and A succeeds but B
   fails, C and D will not be consumed until B either succeeds or gets
   poisoned (i.e. moved to the DLQ).

Hope this helps.


 *Raúl Kripalani*
Principal Consultant | FuseSource Corp. | <>
skype: raul.fuse | twitter: @raulvk <>,

On 4 April 2012 13:18, ctytgat <> wrote:

> asyncConsumers certainly won't help me with maintaining the order.
> I'm currently trying to implement something around AMQ message groups after
> all.
> Writing some custom sequencing and error handling code might do the trick.
> Won't be a very clean solution though.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

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