Competing consumers with AZ slots

,
1

Hey, I am very new to NSB, I have inherited it from another team. I am attempting to make some developer experience improvements, mainly around us not being able to use deployment slots for testing because our messages get stolen between webjobs.

We have AzureServiceBus as the transport, using a single queue for everything and not topics. I cannot for the life of me figure out how to stop events making it to the main queue from the deployed slot though, so my events are basically getting subscribed to from both the main queue and the slot queue, my assumption is that it is because of the name of the event and it is going into the broker “pot” without caring where it came from.
With SQL transport I am able to get around this by amending the schema to use the slot name in the SubscriptionTableName setup - but there doesn’t seem to be an equivalent to this with ASB transport using auto-subscriptions. The only thing I can currently think is to disable auto-subscribe and manually configure all subscriptions (100s of events) to match the slot specific queue name, but this seems painful.

I was fiddling with the SubscriptionRuleNamingConvention to use a slot name, but it didn’t seem to make a difference and also constantly exceeded the 50 char limit, but maybe I have misunderstood how that is working.

Any assistance would be greatly appreciated!

2

Another option is to use a different ASB namespace (aka ‘pot’) for you non-production slot.

3

Could you point me in the direction of this in the docs, or the syntax for googling? I originally thought I was doing that by having 2 queues with different names “slot-queue” and “queue”, but obviously I have learnt that the pub/sub doesn’t work like that.

4

A different queue in the same namespace would be fine as well. When I had to do this (about 10+ years ago), I had to tweak the settings during CI/CD. And restore the queue name when swapping slots.

5

Hmm the message is going to both of the queues, and I suspect it is because the name of the subscription is clashing so both queues have the same list

6

I don’t know what your topology looks like, but it needs to be separate for each environment. In your case, the slot should have its own topology. That is why in my previous experience a separate namespace was an easier solution as it was just a connection string that needed to be different. The apology could be identical.

7

I have made a little progress, at least in understanding the full flow of the system! But I have found my issue, although I have changed the name of the subscription, the contents of the rule is still doing a like on the [NServiceBus.EnclosedMessageTypes] as per the docs. We are a single topic structure, which is where the issue is - do you happen to know if this filter can be changed programmatically?

8

For our understanding.

  • You have different AZ slots
  • These slots share the same Azure Service Bus namespace
  • You deploy the same endpoint but a different version to each slot
  • These use a different name so each gets its own queue in the namespace
  • You notice that both share the same topic and each get a copy of of any published even in either slot

Not fully clear if this is the problem but it seems you have a few options:

However, I wouldn’t advice this approach. Especially with the knowledge that we just released version 5 of our Azure Service Bus transport that uses a different topology.

What friction are you experiencing if you would to for a namespace per slot approach?

– Ramomn

9

Thank you @ramonsmits - using a different bundle topic was EXACTLY what I needed, it is annoying that it is not clearer in the docs, or at least wasn’t for me, and it took me a bit to figure out that bundle-1 even existed as newbie! Thank you!

10

Hi,

Glad to know the custom bundle topic was of help to you. But please note that the new version of the transport uses a different topology.

Is there any reason why another namespace cannot be used for the slot? Are you using a premium or standard namespace?

Poornima