Can I use RPCClient with fanout exchange?

Question

I'm new to RabbitMQ and needs some advice.

I have a situation where I need to broadcast a message and then wait for a response in a timely fashion. In other words, the broadcast message expects a response within a timeout period from all subscribing consumers. It's straightforward with direct exchange. I can use a RPCClient to wait for the response. How does it work with fanout exchange? Would it know how many subscriber to wait for? Or would it return successfully after the first response?

If I create a fanout exchange and pass it in when creating the RPCClient object. Then implement my own consumer and and the consumer consumer from the same exchange and sender send to the same reply-to queue. Would it work?

Please advise. Thanks!

Answer 1

Here is your issue:

the broadcast message expects a response within a timeout period from all subscribing consumers.

I added emphasis to illustrate an anti-pattern in your design. The concept behind a broadcast is that the broadcaster neither knows nor cares about who is listening to it. By creating a constraint on the broadcaster to know who is listening, you have effectively changed a broadcast into a bunch of unicasts, but are attempting to do so without actually admitting it.

Now, let me describe a more viable scenario without using the word all.

1. You send a broadcast message via a fanout or topic exchange.
2. Consumers receive the message
3. Consumers send a new message to a reply queue via a direct exchange as designated within the original broadcast message.
4. A consumer reading from the reply queue consumes messages until the end of the timeout period.

Hopefully all consumers have replied, but there is no way to know. If you require a 1 to 1 correspondence between consumer and broadcaster, your situation becomes a lot more complicated and a broadcast is no longer the appropriate venue.

Answer 2

Yes it will work. RPC is a pattern (if we exclude direct reply to) not bound to a direct exchange. You can apply this pattern to a fanout exchange.

Instead of waiting for one reply, wait for the expected replies or until the timout is reached.

The knowledge of expected replies and fanout exchange are usually antinomic. So you could only rely on the timeout.