bus.Unsubscribe<T>() in NSB 5.x

1

We currently have a handler that was removed from an endpoint in our production environment that was handling an event. The MEM (config-based) was removed along with the handler, but it looks like the subscription was never cleared from the publishing endpoint, so we’re getting a bunch of these failures in ServicePulse:

“No handlers could be found for message type: [MessageType]”

bus.Unsubscribe looks as if it’s meant to handle this scenario. My guess is that the bus.Unsubscribe call should be put into the subscribing endpoint?

However, because the MEM has been removed from the subscribing endpoint, how is bus.Unsubscribe supposed to find it’s way back to the message publisher to clear the subscription?

Thanks,
Mike

2

Hi Michael

Would the following example help?

You could also go on the lower levels and remove the entry in the subscription storage you are using.

Regards
Daniel

1 Like
3

Daniel,

I did see that page earlier, but it only has NSB 6.x and 7.x as options for Version. I’m trying to unsubscribe using NSB 5.x

4

What transport are you using?

I think it might be easier just to go into the subscription storage or the broker and manually remove the subscription/binding.

5

Andreas,

We’re using MSMQ for the transport and NHibernate for persistence. Sounds like going straight to the “Subscriptions” table for the publishing endpoint in the database and deleting the subscription entry out would be the “easiest” way to do it?

Thanks,
Mike

6

Yea, just execute a:

DELETE FROM [dbo].[Subscription]
      WHERE SubscriberEndpoint = 'MyEndpoint@MyServer' AND
	  MessageType = 'MyMessage'

The publisher should pick up the change right away unless you have turned caching on NHibernate Persistence • Particular Docs

1 Like
7

Forgot to link to our doco on this topic

1 Like
8

Andreas, thanks so much for the help.

9

So I have a question about the mechanics behind how a publishing endpoint gets a list of subscribers for a given event at the point the endpoint is going to publish the event. If caching is turned off (which is our case), then does the publishing endpoint do a read on the Subscription table every time it needs to publish an event to get a list of subscribers or does the publishing endpoint load the list of subscribers from the Subscription table into memory when it the endpoint starts?

10

Hi @mgmccarthy,

it’s up to the persister to decide what to do. If I recall correctly the current behavior is that by default the persister will query the storage every single time a request for publish is issued. At least this is what the RavenDB persister does. Each persister can then allow users to configure caching strategies so that the storage is not stressed to much, especially because we do not expect subscriptions to change that frequently.

.m