You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "FERRY, Guillaume" <gu...@bertin.fr> on 2021/05/11 13:23:11 UTC
[camel-rabbitmq] - InOut pattern and temporary queues
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.
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by "FERRY, Guillaume" <gu...@bertin.fr>.
I also expected the rabbitmq component to handle these IDs by itself.
I'll give a closer look to message headers, there's something fishy going on.
Thanks for you answer !
Regards,
Guillaume.
________________________________
De : Claus Ibsen <cl...@gmail.com>
Envoyé : jeudi 10 juin 2021 06:56
À : users@camel.apache.org <us...@camel.apache.org>
Objet : Re: [camel-rabbitmq] - InOut pattern and temporary queues
On Wed, Jun 9, 2021 at 4:40 PM FERRY, Guillaume
<gu...@bertin.fr> wrote:
>
> Hi folks,
>
> Here's a quick follow-up on my work with camel-rabbitmq.
> So far, everything runs quite smoothly, but in some particular cases, some messages being sent on a queue are not received on the other side.
>
> Here's the relevant log section :
>
> DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: media_text_processing with CorrelationId: null
>
Yes I think this is a strong indicator that this is the problem, as if
there is no correlation id, then then reply message cannot be "matched
up" against the expected request message to known when its
corresponding reply message was received
and allow to continue to route.
However I would also assume that the rabbitmq component (or rabbitmq
client) would be able to auto generate an uuid as correlation id if
you have not provided one specific.
At least JMS can do that.
> My question is simple : is it because CorrelationId is null ?
> If that's, then I guess I'm having an intermediate processor that removes this mandatory header.
>
> Thanks in advance !
>
> Regards,
> Guillaume.
> ________________________________
> De : FERRY, Guillaume <gu...@bertin.fr>
> Envoyé : mercredi 12 mai 2021 15:33
> À : users@camel.apache.org <us...@camel.apache.org>
> Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues
>
> 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 <jb...@nanthrax.net>
> Envoyé : mardi 11 mai 2021 17:59
> À : users@camel.apache.org <us...@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 <gu...@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 <ra...@gmail.com>
> > Envoyé : mardi 11 mai 2021 15:38
> > À : users@camel.apache.org <us...@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.ferry@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.
> >>
> >>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jun 9, 2021 at 4:40 PM FERRY, Guillaume
<gu...@bertin.fr> wrote:
>
> Hi folks,
>
> Here's a quick follow-up on my work with camel-rabbitmq.
> So far, everything runs quite smoothly, but in some particular cases, some messages being sent on a queue are not received on the other side.
>
> Here's the relevant log section :
>
> DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: media_text_processing with CorrelationId: null
>
Yes I think this is a strong indicator that this is the problem, as if
there is no correlation id, then then reply message cannot be "matched
up" against the expected request message to known when its
corresponding reply message was received
and allow to continue to route.
However I would also assume that the rabbitmq component (or rabbitmq
client) would be able to auto generate an uuid as correlation id if
you have not provided one specific.
At least JMS can do that.
> My question is simple : is it because CorrelationId is null ?
> If that's, then I guess I'm having an intermediate processor that removes this mandatory header.
>
> Thanks in advance !
>
> Regards,
> Guillaume.
> ________________________________
> De : FERRY, Guillaume <gu...@bertin.fr>
> Envoyé : mercredi 12 mai 2021 15:33
> À : users@camel.apache.org <us...@camel.apache.org>
> Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues
>
> 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 <jb...@nanthrax.net>
> Envoyé : mardi 11 mai 2021 17:59
> À : users@camel.apache.org <us...@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 <gu...@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 <ra...@gmail.com>
> > Envoyé : mardi 11 mai 2021 15:38
> > À : users@camel.apache.org <us...@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.ferry@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.
> >>
> >>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by "FERRY, Guillaume" <gu...@bertin.fr>.
Hi folks,
Here's a quick follow-up on my work with camel-rabbitmq.
So far, everything runs quite smoothly, but in some particular cases, some messages being sent on a queue are not received on the other side.
Here's the relevant log section :
DEBUG o.a.c.c.r.RabbitMQMessagePublisher - Sending message to exchange: media_text_processing with CorrelationId: null
My question is simple : is it because CorrelationId is null ?
If that's, then I guess I'm having an intermediate processor that removes this mandatory header.
Thanks in advance !
Regards,
Guillaume.
________________________________
De : FERRY, Guillaume <gu...@bertin.fr>
Envoyé : mercredi 12 mai 2021 15:33
À : users@camel.apache.org <us...@camel.apache.org>
Objet : RE: [camel-rabbitmq] - InOut pattern and temporary queues
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 <jb...@nanthrax.net>
Envoyé : mardi 11 mai 2021 17:59
À : users@camel.apache.org <us...@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 <gu...@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 <ra...@gmail.com>
> Envoyé : mardi 11 mai 2021 15:38
> À : users@camel.apache.org <us...@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.ferry@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.
>>
>>
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by "FERRY, Guillaume" <gu...@bertin.fr>.
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 <jb...@nanthrax.net>
Envoyé : mardi 11 mai 2021 17:59
À : users@camel.apache.org <us...@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 <gu...@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 <ra...@gmail.com>
> Envoyé : mardi 11 mai 2021 15:38
> À : users@camel.apache.org <us...@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.ferry@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.
>>
>>
Re: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gu...@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 <ra...@gmail.com>
> Envoyé : mardi 11 mai 2021 15:38
> À : users@camel.apache.org <us...@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.ferry@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.
>>
>>
RE: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by "FERRY, Guillaume" <gu...@bertin.fr>.
Hi Raymond,
Thanks a lot for this crystal clear answer.
I'll let Camel handle theses queues, then !
Best regards,
Guillaume.
________________________________
De : ski n <ra...@gmail.com>
Envoyé : mardi 11 mai 2021 15:38
À : users@camel.apache.org <us...@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.ferry@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.
>
>
Re: [camel-rabbitmq] - InOut pattern and temporary queues
Posted by ski n <ra...@gmail.com>.
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.ferry@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.
>
>