rebus-org / Rebus.AzureServiceBus

:bus: Azure Service Bus transport for Rebus
https://mookid.dk/category/rebus
Other
33 stars 20 forks source link

Add support for Session queues #41

Closed tinlong closed 4 years ago

tinlong commented 4 years ago

Hi,

I am trying to use Rebus at work along with Azure, and while gathering requirements, it came that we might need ASB's ability to have session queues (group-id in AMQP). As I have looked through the code, the current Rebus.AzureServiceBus transport does not create or utilize session queues. Is there any plan to support it, or is it a conscious decision to leave it out? I have written some test code and it seems doable in Rebus.

Please let me know your thought and I appreciate your attention. If you would like, I could contribute to the code.

Best Regards, Patrick

mookid8000 commented 4 years ago

When I've come across Azure Service Bus' more esoteric features, like support for groups/session, I've sometimes considered it. I usually come to the conclusion that it doesn't really fit into Rebus, though.

In the case of message groups/session, it would require some pretty substantial changes to how Rebus' ASB transport receives messages. With some clever coding, this could end up being tolerable, but my fear is that it would complicate the code too much to try to make this fit into Rebus' very simple model of receiving one single message at a time (possibly in parallel).

But the most important thing IMO is that making message consumers require a specific order of messages is just bad, because there can be many different reasons why messages arrive in a different order that they were sent in – the two most most prominent reasons being

  1. processing a message, which has been dead-lettered and thus has been sitting in an error queue for some time, and
  2. processing messages in parallel (competing consumers – either in separate processes, or simple by running your Rebus instance with max parallelism > 1)

Both of these reasons require that your consumer handles concurrency and reordered messages* to some extent, which will result in very robust software.

This does not means that I am completely against the feature that ASB provides – it just means that, all things considered, my current belief is that it's not a good fit for Rebus.

If you believe something else, feel free to try to convince me 😃 e.g. I'm curious as to how you imagine the API in Rebus would look like when using this feature....?


(*) Regarding reordered messages:

I do not recommend coding so defensively that ALL kinds of reordered messages can be handled – in some cases, one might decide that the likelihood of some specific messages arriving in the wrong order is very low, and so it doesn't make sense to handle that particular situation.

In most situations though, I recommend that you model your way out of it, so your messages are independent and can be processed in any order and your consumer will still end up in the same state.

mookid8000 commented 4 years ago

I'll close this issue for now, as it's not really an issue 🙂 feel free to keep the talk going in here anyway, if you like!