Search code examples
nservicebusazure-table-storagepublishersubscriberazure-storage-queues

Is it possible to scope/group event publishers in NServiceBus?

I have:
- one subscriber SUB with QUEUE0
- publisher PUB1 with QUEUE1
- publisher PUB2 with QUEUE2
- event MyEvent being published by both publishers

When:
- SUB explicitly subscribes to PUB1 with queue name QUEUE1 only

subscriberEndpointConfiguration.UnicastRouting().AddPublisher("PUB1", typeof(MyEvent));

Outcome:
- SUB also receives MyEvent from PUB2 (which has queue name QUEUE2)

Expected:
- SUB should not receive MyEvent from PUB2, because it's not subscribed to that publisher queue name

From NSB wiki:

subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are

Questions:

  1. What's the point of specifying the publisher endpoint in the AddPublisher method shown above? The Subscription table in the Azure Table Storage has an event type and a subscriber columns only, publisher endpoint is not stored.

  2. If AddPublisher is some sort of an obsolete method, then the endpointInstance.Subscribe<MyEvent>() simply fails - it says "no publishers could be found".

  3. Is it possible to scope/group publishers so having only one event type MyEvent the subscribers will receive that events from publishers which are created with the same queue name only?
    E.g. you create PUB1 with QUEUE-A, PUB2 with queue QUEUE-A, PUB3 with QUEUE-B, and SUB with AddPublisher to QUEUE-A, so the SUB does not receive MyEvent from PUB3 (QUEUE-B).

I'm using:
NServiceBus 6.0.0-beta0004
NServiceBus.Persistence.AzureStorage 1.0.0-beta0004
NServiceBus.Azure.Transports.WindowsAzureStorageQueues 7.0.0-beta0004

Solution

    1. Azure Storage Queues transport supports pub/sub using persistence. The need to specify the publisher endpoint is there to allow sending a subscription message by the subscriber upon startup. By default, all endpoints use the same shared storage table and that's why you experience what you describe. If you'd split subscriptions per endpoint (each endpoint to have its own storage table), you'd see that SUB would only receive an event from PUB1 if that's the only publisher it's subscribed to.

    2. AddPublisher() is not an obsolete method. Obsoleted message would be marked as such. Saying that, the routing feature still can be modified during the beta stage we're in right now.

    3. Scoping can be done the way Philip outlined. At the same time, I would encourage to look into why you have two different endpoints generating the same event. Usually, you'd want to have an event be unique and raised by a single endpoint (or, all of it instances), but not two or more different endpoints.