RPC tutorial questions regarding the queue and channel

[wigging]

I went through the RPC tutorial on the RabbitMQ website and have some questions.

Why does the client code (see below) not define the queue name? For example, instead of using queue_declare(queue='', exclusive=True), it seems like you could just do something like queue_declare(queue='client_queue', exclusive=True) where the name of the queue is explicitly defined.

result = channel.queue_declare(queue='', exclusive=True)
callback_queue = result.method.queue

In the server portion of the code (see below), which channel ch is being used in the callback function? Is it the same channel such as channel = connection.channel() that is defined earlier in the code?

def on_request(ch, method, props, body):
    ...

[michaelklishin]

@wigging you can use an client-provided queue name but since that is a response queue, that won't work very well once you have N clients. Therefore server-named queues are used for response (request-reply client-owned) in the tutorial.

This is different from request-reply server queues which can and usually are explicitly named and "well-known" in the overall system. N competing consumers (server instances) on such queues pose no problem and create no confusion.

The channel used in Pika's callbacks is the channel the delivery arrived on, which is the channel you have registered the consumer on.

[michaelklishin]

I'd also add that #12181 (comment) is relevant to the request-reply messaging pattern, and provides another sound justification for the use of server-named temporary queues for reply collection.

[wigging]

Ok, so when I have multiple clients they can't use the same response queue; therefore, the tutorial uses a server-named queue. But why can't multiple clients use the same queue? It seems like using the same response queue would be more efficient than creating a new one for each client.

[michaelklishin]

For the same reason why not having shared state is often necessary or a very good idea. How would they determine which delivery is theirs? Yes, using correlation_id and other metadata fields, but they they would have to requeue most of deliveries.

In AMQP 0-9-1, the idea that one client often means one queue, and that eliminates the need for a "query language" and so on, is everywhere.

The tutorials do not use this feature because their goal is to demonstrate the concept but for 11 years now, there exists a way to not declare any response queues specifically for this pattern. It has its downside of not being a "real queue" but for transient responses that's usually fine, or you can do what tutorial 6 does, or even try what you had in mind (now being aware of the risks and complexities of such shared client state).

[wigging]

Thank you for the explanation.