Hi Raymond, Thanks a lot for this crystal clear answer. I'll let Camel handle theses queues, then !
Best regards, Guillaume. ________________________________ De : ski n <raymondmees...@gmail.com> Envoyé : mardi 11 mai 2021 15:38 À : users@camel.apache.org <users@camel.apache.org> Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues When working with a Request-Reply pattern the reply message needs to send to a second reply queue. The InOut pattern mostly goes like this: 1) Producer send request with correlationid to a queue 2) Consumer receives the message and send a reply to the reply queue 3) Producer matches the reply message through the correlationid and consumes the reply. If there is no matching message a time out is thrown. There are two options for the Reply Queue: 1) Temporary queue. 2) Fixed queue. Producer sets a fixed queue through the "ReplyTo" header/parameter. Temporary queues are the default behavior. In general, it's easier to let the correlationid and temporary reply handled by Camel and the Broker. In some cases you need to fall back to fixed reply queues. Regards, Raymond Op di 11 mei 2021 om 15:23 schreef FERRY, Guillaume < guillaume.fe...@bertin.fr>: > Hi everyone, > > I'm developing an application that relies mostly on Camel (3.9.0) and its > dedicated RabbitMQ / REST components. > My routes are specified in XML (with Spring beans). > > Here's a simple route : > > <camel:rest path="/percolate"> > <camel:post> > <camel:route> > <camel:log message="in :: percolate" logName="app.log" /> > <camel:inOut uri="rabbitmq:percolate?queue=percolate_queue"/> > </camel:route> > </camel:post> > </camel:rest> > > The percolate_queue defined in another XML contains a single Camel > processor, which returns a basic JSON. > > When I'm calling the REST endpoint : > > * A message is sent to percolate_queue without issues > * The Camel processor is invoked, and returns its value (which I get > as a response for my REST call) > > However, I noticed a temporary queue amq.gen.XXX has been created > automatically, to handle the reply. > Is it the standard behaviour ? > > Before using camel-rabbitmq, we were relying on camel-spring-amqp ( > https://github.com/Bluelock/camel-spring-amqp), which is now obsolete > (and triggered the switch to camel-rabbitmq). > And with this component, we did not have any temporary queues for this > kind of routes. > > May it be because the replyTo property (CamelRabbitmqReplyTo) is not set ? > If so, how can I set/adjust it to point on the existing percolate_queue ? > > Thanks a lot for your answers. > > Best regards, > Guillaume. > >
