Nservicebus Azure service bus - Taking control on subscriptionclients?

[Haripraghash Subramaniam]

Helpful information to include

Product name: NSB ASB 7.1.3

Version:

Stacktrace:

Description:

Hi,

We have an Azure worker role that hosts NSB with ASB as transport. TThis worker role has 16 handlers which translates to 16 subscriptions on a an ASB topic. I am trying to see if there is a way to take control over the subscription clients being created internally? The reason is, the subscriptionclients created internally by NSB ASB seems to read messages of few subscriptions pretty aggresively and on the other subscriptions not so aggresively. There could be certain scenarios where we would like to process certain messages a bit more aggresively and have others on lower priority. Is there a way to control this? Looks like setting the concurrency affects all the subscription client created internally.

[Dennis van der Stelt]

Hi Haripraghash,

NServiceBus doesn't support priority messages or priority queues. We think the best way to deal with this is via different endpoints. So basically you set up a different endpoint to handle messages with a higher priority. However in most cases (it always depends) it's not wise to have the sender of the message decide to which queue a message has to go. That would indicate coupling between the two endpoints.

Take this example : Imagine two customers, one being a preferred customer, the other one a regular customer. Set up an endpoint to handle regular customers and an endpoint to handle preferred customers. Have them both subscribed to the event that something happened, for example an order that needs to be processed, or shipped, or whatever. The preferred customer endpoint throws away 98% of the messages, since they are for regular customers. This empties out this queue really, really fast and it's probably empty most of the time. The endpoint for regular customers has to deal with the other 98% of the messages and thus has a lot more work to do. It throws away 2% of the messages, since it knows it's not responsible for preferred customers.

The idea is that both endpoints can have different SLAs. You also have the option to scale out the preferred customer endpoint, without having to think about the regular customer endpoint. Or vice versa. Have one of them high available and the other one not, or have less constraints fo high availability. All depending on the needs of the business. You have options on how to recognize regular from preferred customers. For example have an in-memory list of all preferred customers. Lots of options here.

The sender side has no knowledge of what is happening to whatever customer. It is not its concern.

I hope this helps clarify how we think you should deal with these kind of scenarios. If your scenario is different or you have additional questions, don't hesitate to ask.

Regards,

Dennis van der Stelt

Particular Software

http://particular.net/