2

у меня есть:
- один абонент SUB с QUEUE0
- издатель pub1 с queue1
- издатель PUB2 с QUEUE2
- события MyEvent публикуемой обоими издательствамиВозможно ли охватить/группу издателей событий в NServiceBus?

Когда:
- SUB явно поддерживает pub1 с именем очереди queue1 только

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

Результат:
- SUB также прн eives MyEvent из PUB2 (который имеет имя очереди QUEUE2)

Ожидаемый:
- SUB не должен получать MyEvent от PUB2, потому что это не подписалось на это имя очереди издателя

От NSB вики:

подписчики выражают интерес к одному или нескольким классам и получают только сообщения, представляющие интерес, без знания того, что, если таковые имеются, есть

Вопросы:

  1. Что точка указания издателя конечной точки в методе AddPublisher показано выше? Таблица подписки в хранилище таблиц Azure имеет тип события и только столбцы подписчика, конечная точка издателя не сохраняется.

  2. Если AddPublisher - это своего рода устаревший метод, то endpointInstance.Subscribe<MyEvent>() просто терпит неудачу - он говорит: «издателей не найдено».

  3. Возможно ли, чтобы издатели области/группы имели только один тип события MyEvent, подписчики получат эти события от издателей, которые созданы только с тем же именем очереди?
    E.g. вы создаете PUB1 с QUEUE-A, PUB2 с очередями QUEUE-A, PUB3 с QUEUE-B и SUB с AddPublisher до QUEUE-A, поэтому SUB не получает MyEvent из PUB3 (QUEUE-B).

Я использую:
NServiceBus 6.0.0-beta0004
NServiceBus.Persistence.AzureStorage 1.0.0-beta0004
NServiceBus.Azure.Transports.WindowsAzureStorageQueues 7.0.0-beta0004

+0

Являются ли оба Pub1 и Pub2 использующими те же 'IEndpointInstance'? (в основном на том же хосте). И используют ли они ту же конфигурацию Persistance: 'busConfiguration.UsePersistence (). TableName (" tableName ")'? Я думаю, что каждому издателю будет нужна не только его собственная очередь (для получения в будущих подписных сообщениях), но и ее собственная таблица Persistence для хранения подписки. Я не думаю, что издатели могут делиться таблицей без кровотечения. –

ответ

3
  1. Azure Storage Очереди транспорт поддерживает pub/sub using persistence. Необходимо указать конечную точку издателя, чтобы разрешить отправку подписного сообщения подписчиком при запуске. По умолчанию все конечные точки используют одну и ту же общую таблицу хранения, и поэтому вы испытываете то, что вы описываете. Если вы разделили подписки на конечную точку (каждая конечная точка должна иметь собственную таблицу хранения), вы увидите, что SUB получит только событие от PUB1, если это единственный издатель, на который он подписан.

  2. AddPublisher() не является устаревшим методом. Обозначенное сообщение будет помечено как таковое. Говоря о том, что функция маршрутизации по-прежнему может быть изменена во время бета-стадии, в которой мы сейчас находимся.

  3. Сфера охвата может быть выполнена так, как намек Филиппа. В то же время я бы посоветовал посмотреть, почему у вас есть две разные конечные точки, генерирующие одно и то же событие. Обычно вы хотите, чтобы событие было уникальным и воспитывалось с помощью одной конечной точки (или всех ее экземпляров), но не с двумя или более разными конечными точками.

+0

У нас есть сценарий, в котором у нас есть общая реализация службы, где каждый экземпляр имеет собственную группу заинтересованных подписчиков. Кроме того, мы хотели бы отмечать события, поэтому только конкретным абонентам можно получить событие. –

1

Каждому издателю нужна своя таблица сохранения, в дополнение к собственной очереди.

При настройке каждого издателя IEndpointInstance:

busConfiguration 
    .UsePersistence<AzureStoragePersistence, StorageType.Subscriptions>() 
    .TableName("NameOfPublisher") 

Смотрите документацию для получения дополнительной информации: http://docs.particular.net/nservicebus/azure-storage-persistence/configuration