Nservicebus: MSMQ Subscription Storage does not update subscriptions

[timbussmann]

Symptoms

When using MSMQ Subscription Storage and upgrading from Version 5, sender-side distribution might send duplicate events to scaled-out subscribers.

Who's affected

Systems configured using MSMQ Subscription Storage which use sender-side distribution in NServiceBus Version 6.

---

MSMQ subscription storage does not overwrite existing subscriptions if a new subscription for the same address arrives. This behavior is required because with v6 we send along additional important information for sender-side distribution. InMemory and NHibernate persistence replace the existing subscription with the new one which allows for a proper migration scenario.

[andreasohlund]

Agreed, we only support a local queue. That said I guess you could scale out on the same machine?

[andreasohlund]

But then you would just be competing consumer so I think we're good

[timbussmann]

What I realized is that with v6, you could actually use the msmq subscription storage on scaled out instances because we send subscribe and unsubscribe messages to all instances. In this case, this bug could cause potential issues. But after talking to @bording we saw that the documentation already states that msmq sub. storage is not suitable for scale out scenarios. So from this perspective, we can keep that storage as "unsupported for scale-out" for now, so again, I think this is not critical right now (unless we find another impact of the described behavior which can cause issues?). Thoughts @Particular/nservicebus-maintainers ?

[danielmarbach]

Should we close as Won't fix?

[timbussmann]

I still think we should "fix" it (or rather implement it as a feature). How about raising a new issue for a "support msmq subscription storage for scaled out endpoints" feature?

[danielmarbach]

Good and then we can close this one. @timbussmann can you do it?

[timbussmann]

will do.

[timbussmann]

I think this may be an issue after all: When using msmq subscription storage on a non-scaled out instance which publishes events to scaled out subscribers, the mentioned behavior will cause issue with the suggested distributor upgrade path. V6 adds additional information the subscription which is relevant for sender-side distribution. If an existing subscription does not update with the additional information from an upgraded worker, this can cause duplicate messages.

[danielmarbach]

Then let's bite the bullet and fix it.

[timbussmann]

closing this as it has been fixed with #4155