Hi Souciance, I did exactly what you propose in the second part of your reply. I split the flow into 2 steps: 1) send out the request to multiple consumers via the fanout exchange with inOnly pattern; 2) aggregate the reply messages in another route, that consumes the replies from a fixed response queue, and send a response to the original caller.
It works but just as you wrote, it's a bit messy. Besides, this way the processing of the original request/order gets acknowledged at the end of the first step/route (even with autoAck=false) and not at the end of the real processing, which would be the end of the second step/route. Otherwise, you're right. I haven't seen such a request-(multi-)reply pattern in RabbitMQ, though I think that as far as RabbitMQ is concerned, it could work. It doesn't require anything from RabbitMQ that it cannot do/provide. As I wrote, I almost made it in a single route with inOut pattern and Camel RabbitMQ's temporary reply manager. The "only" missing piece is to "combine" the aggregator to the reply manager so that it doesn't stop listening on the first reply but waits for further replies as configured for the aggregator (completionCount, completionTimeout, etc.). Anyone who have done anything like this before? Or at least who could give some hints how to tailor the reply manager for this purpose? Cheers Andras -- View this message in context: http://camel.465427.n5.nabble.com/RabbitMQ-fanout-exchange-request-reply-aggergator-tp5796289p5796437.html Sent from the Camel - Users mailing list archive at Nabble.com.
