Automatically Unsubscribe to old Events in RabbitMQ

[Jake Stevenson]

Helpful information to include

Product name:NServicebus

Version:5.0.3

Stacktrace:

Description:

We are using RabbitMQ as our message broker.  We hit a strange situation where one of our NServicebus Hosts had previously been configured to Autosubscribe to events, but that feature was later disabled.  The person who disabled the feature neglected to manually subscribe to some events, but since the code to handle those events still existed and the RabbitMQ exchange was never removed, the host still performed as expected.  It was only once we had an issue that caused us to rebuild our RabbitMQ server from scratch that we noticed the application no longer worked as expected.

We're also concerned about a future where we may decide a host no longer cares about specific events, but would still get the messages and throw errors about it.

What can we do to prevent this from biting us again in the future?  We could as part of deployment write code that scans all exchanges for our own queue and remove the bindings, but that seems like an awful lot of work for this.  Does NServiceBus provide some sort of automated way to handle this?  

[Andreas Öhlund]

>We are using RabbitMQ as our message broker.  We hit a strange situation where one of our NServicebus Hosts had previously been configured to Autosubscribe to events, but that feature was later disabled.  The person who disabled the feature neglected to manually subscribe to some events, but since the code to handle those events still existed and the RabbitMQ exchange was never removed, the host still performed as expected.  It was only once we had an issue that caused us to rebuild our RabbitMQ server from scratch that we noticed the application no longer worked as expected.

Not sure there is much we can do here since it's valid to setup queues and exchanges manually so I think you need to handle this by making sure to run some suite of tests on a "fresh" broker before you deploy.

>We're also concerned about a future where we may decide a host no longer cares about specific events, but would still get the messages and throw errors about it.

Since it's would mean message loss if subscriptions are incorrectly removed NServiceBus just provide means for you to explicitly unsubscribe using `IBus.Unsubscribe`.

http://docs.particular.net/nservicebus/messaging/publish-subscribe/how-to-pub-sub#how-to-subscribe-to-a-message-

>What can we do to prevent this from biting us again in the future?  

How much of a problem is this? 

In my experience it's quite rare that you want to stop receiving events and I've mostly handled it manually.

>We could as part of deployment write code that scans all exchanges for our own queue and remove the bindings, but that seems like an awful lot of work for this.  Does NServiceBus provide some sort of automated way to handle this?  

Other than unsubscribe no. Other options is like you mention to write scripts against the underlying broker/storage/etc to clear out unwanted subscriptions.

That said I would be very cautious with this since it can cause havoc if something should go wrong. Imaging that you wipe all subscriber for a given event when redeploying an endpoint. All events published until you detected the issue would have to be replayed in some way to recover. 

In short: Is this really an issue? 

If it's indeed an issue can you share more details on what types of events you have that needs to be unsubscribed to frequently?

Cheers,

Andreas

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/f4f882d5-31c1-40d3-b511-718255aff9a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jake Stevenson]

How much of a problem is this? 

So far it has only bitten us that one time.  It hasn't been a repeated problem so much as something that has caused a great deal of concern within our QA team.  We had no idea the "problem" even existed until we had a rabbit failure, and we expected that everything would come right back up when the hosts were restarted.   It wasn't until we had done a full regression test that we found that a Host was not receiving the messages in that environment, but did in our other environments.  We don't EXPECT to see it happen again much in the future, and we know to look out for it, but you rarely expect a problem untilI  it's biting you.

Not sure there is much we can do here since it's valid to setup queues and exchanges manually so I think you need to handle this by making sure to run some suite of tests on a "fresh" broker before you deploy.

I can't imagine being able to do this through scripting without the possibility of losing messages.  However, if the NServicebus pipeline was smart enough it could possibly handle it.  As part of the pipeline, AFTER subscribing to the queues it knows it should, it could scan the exchanges for any other subscriptions that were not expected.  It could then remove them (maybe if the bus was configured to AutoRemoveOldSubscriptions).  

Again, it's only bitten us this once.  But it was a tricky surprise, and we'd like to do our best to ensure we don't get surprised by it again in the future.