RabbitMQ RPC single durable reply-to queue

[Paweł Piotrowski]

I am new to RabbitMQ, I followed the Tutorial 6 on RPC as I need something similar but I don't quite like the idea of temporary queues that are destroyed after recieving the reply.

Documentation says:

"The client can declare a single-use queue for each request-response pair. But this is inefficient; even a transient unmirrored queue can be expensive to create and then delete (compared with the cost of sending a message).[...]

So alternatively the client can create a long-lived queue for its replies. But this can be fiddly to manage, especially if the client itself is not long-lived."

I am planning to have one durable rpc queue and one durable rpc reply queue. Client will be taking the messages and matching by looking at correlation id.

So I tried to create a long lived reply queue that won't be deleted and won't be auto generated, defining it as follows:

replyQueueName = channel.QueueDeclare(queue: "rpc-reply-queue",

                      durable: true,

                      exclusive: false,

                      autoDelete: false,

                      arguments: null).QueueName;

Is there anything wrong with such approach? What can happen if client is not long-lived? I tested it and it seems to be working fine. Just wanted to make sure there are no side effects to this approach.

Documentation suggests to use Direct Reply-to feature, what would be better? My approach seems to be easier but I am not sure if it's correct.

Thanks in advance.

[Brian Richardson]

Hello Pawel,

Typically yes, you will declare the reply queue as exclusive (with some sort of unique identifier in the queue name) and use reply-to feature instead of queue bind. It's the "unique identifier" part that usually necessitates the auto-delete. But if you always recreate your clients with the same unique identifier and can enumerate them, then you don't need to auto-delete. So, it sounds like your approach will work for your solution.

In most of my web applications though, there aren't any short-lived clients. They will persist for the lifetime of the web application or worker service. In this case, the cost of auto-delete is really quite neglible.

Regards,

Brian Richardson

IT Architect

br...@cubik.ca

---

From: rabbitm...@googlegroups.com <rabbitm...@googlegroups.com> on behalf of Paweł Piotrowski <graf...@gmail.com>
Sent: Friday, June 18, 2021 5:17 AM
To: rabbitmq-users
Subject: [rabbitmq-users] RabbitMQ RPC single durable reply-to queue

 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/effe047a-0569-496b-bee4-1ed265b2ad86n%40googlegroups.com.

[Paweł Piotrowski]

Hi Brian,

Thanks for the reply.

In my scenario user will be invoking API method that does something and it will spawn a RabbitMQ RPC client and will asynchronously wait for the result so it will be relatevely short lived that's why I thought a durable queue that stores the replies will be better. Am I correct?

Regards,

Pawel