multiple request/reply with same replyQueue

MATT CHEUNG

Hi all,
I am handling this situation and hoping for solution:
Supposed there are two identical requestors sharing the same replyQueue to receive the replies. They will regularly send a request to a consumer. How can I ensure that the replies can be received by the correct requestor (the one who really send the request) but not the other?
Thanks

TomF

Hi @MATT CHEUNG , there is a good way to deal with this. I assume you're mapping the "replyTo" topic to the reply queue by having a subscription on the reply queue to the "replyTo" topic. If so, as you say, the queue will contain replies destined for all the requestors. The way to differentiate messages, then, would be to use the correlationID that you can add to a request/reply message. See https://solace.com/samples/solace-samples-java/request-reply/ for examples of Java Request/Reply.

You've then got the problem that all queue consumers need to see all the messages. You could add a user property to your request message which the replier adds to it's reply. The consumer would then use a selector on that user property so that it would only retrieve its own messages from the queue.

However, with a little thought, we can redesign this to be much easier to code, monitor and manage. Imagine one of your requestors misbehaves and fills up your single queue. All your request/reply conversations are now stopped. How do you know which requestor is the problem? How do you fix it?

A better solution would be to have separate queues for the replies for each requestor. That way you have decoupling. You could have a topic structure that has the requestor id as a level of hierarchy (..../requestType/locality/requestorId/requestId - see https://solace.com/blog/topic-hierarchy-best-practices/ for more on topic hierarchy). You requestor specific queue can then just subscribe to .../requestType/locality/thisRequestorId/>.

If you need a queue to hold all the responses, say for logging or auditing, just create a separate logging queue, subscribing to .../requestType/locality/>. Messages can then be read from the logging queue separately from the response queues.