Hi Jean-Baptiste, Thanks for the details, I'll let you know if something goes wrong with temporary queues, so far, it works like a charm.
Best regards, Guillaume. ________________________________ De : Jean-Baptiste Onofre <j...@nanthrax.net> Envoyé : mardi 11 mai 2021 17:59 À : users@camel.apache.org <users@camel.apache.org> Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues Hi Guillaume, Yes, that’s probably the easiest way. To complete a little: - the correlation can be done on the request message id using a temp destination - the correlation can be done on the client ID using physical destinations Most of the time, ReplyTo header contains a physical response destination, where we correlate with the request message ID. Regards JB > Le 11 mai 2021 à 15:42, FERRY, Guillaume <guillaume.fe...@bertin.fr> a écrit : > > 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. >> >>