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 <guillaume.fe...@bertin.fr>
Envoyé : mercredi 12 mai 2021 15:33
À : users@camel.apache.org <users@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 <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.
>>
>>

Reply via email to