1

How does Rebus ensure that a requester gets the response destined for the requester from the server?

The context is a setup with multiple clients, one backend server and two azure servicebus queues one for the client side and one for the server side. One client's response must not be received by another client.

My concern is that Rebus doesn't support sessions on azure service bus.

Jan Rou
  • 151
  • 2
  • 10

1 Answers1

1

How does Rebus ensure that a requester gets the response destined for the requester from the server?

Rebus replies back to the queue specified with the rbs2-return-address header in the request, so if you have multiple instances consuming messages from that queue, then the reply will likely not be received by the original sender.

That's pretty much how it works, so it's important that all Rebus instances that consume messages from the same queue have the same capabilities. This implies that e.g. keeping in-mem, non-distributed state in a process that may receive replies from requests sent by other Rebus instance is a no-go.

If you describe the problem you're trying to solve, then maybe I can give you some inspiration on how to solve it.

mookid8000
  • 18,258
  • 2
  • 39
  • 63
  • Ok! Clients are instances of the same web-application that send requests to the backend over an azure servicebus. The clients are in DMZ . The server backend is behind the firewall and have access to internal systems. The azure servicebus is used in order to avoid direct access from the wild internet. Rebus.Async looks good however it's experimental. Another way may be to code a transport decorator in order to filter responses on an id at the start of the Rebus message pipeline. So a web-app sends a request with its id and peeks the response with its id from the client queue. – Jan Rou Nov 04 '21 at 13:26
  • I've concluded it's bad design not to have a backend in front of the servicebus in the DMZ. The backend will serve as a relay to the frontends and handle odd situations like loss of connection. – Jan Rou Nov 05 '21 at 05:29
  • If the client queues are only meant to be used for request/reply, then you can just give them random names (e.g. a guid), so each client has its own reply queue. If you then remember to set the auto-delete-on-idle flag, the queues will be cleaned up when they're not used anymore. Look here for an example: https://github.com/rebus-org/Rebus.AzureServiceBus/blob/master/Rebus.AzureServiceBus.Tests/WorksWithAutoDeleteOnIdle.cs#L34 – mookid8000 Nov 09 '21 at 15:36