Rebus не может подписаться на несколько конечных точек с одинаковым значением «сообщений»

Question

Есть ли причина, по которой Rebus не может использоваться в протоколе pub/sub, подписываясь на несколько конечных точек, публикующих сообщения из общей сборки?

Когда я пытаюсь настроить подписчика Ребус с этим:

<rebus inputQueue="ocs.subscriber.input" errorQueue="ocs.subscriber.error" workers="1" maxRetries="5"> 
    <endpoints> 
    <add messages="D3A.Messages" endpoint="ocs.publisher.input" /> 
    <add messages="D3A.Messages" endpoint="ocs.publisher.input@osi2552" /> 
    </endpoints> 
</rebus> 

Исключение брошено в

.Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig()) 

за исключением выброшен это:

An unhandled exception of type 'Rebus.Configuration.ConfigurationException' occurred in Rebus.dll 

Additional information: 

An error occurred when trying to parse out the configuration of the RebusConfigurationSection: 


System.Configuration.ConfigurationErrorsException: The entry 'D3A.Messages' has already been added. (C:\projects\OCS.Subscriber\bin\Release\OCS.Subscriber.vshost.exe.Config line 22) 

    at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult) 

    at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject) 

    at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) 

    at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) 

    at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject) 

    at System.Configuration.BaseConfigurationRecord.GetSection(String configKey) 

    at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName) 

    at System.Configuration.ConfigurationManager.GetSection(String sectionName) 

    at Rebus.Configuration.RebusConfigurationSection.LookItUp() 

    at Rebus.Transports.Msmq.MsmqConfigurationExtension.UseMsmqAndGetInputQueueNameFromAppConfig(RebusTransportConfigurer configurer) 

Это кажется бит странный для меня. Похоже, что вполне допустимый прецедент, чтобы иметь подписчика Rebus для нескольких издателей - некоторые из них используют общую сборку POCO.

Какова причина этого ... и (что более важно), есть ли способ достичь этого в Ребусе?

А также: я ожидал, что Rebus добавит это исключение в журнал (я использую log4net), но кажется, что исключения, которые были выбраны во время конфигурации Rebus, не регистрируются. Это, должно быть, ошибка, не так ли?

Answer 1

Причина, по которой она не работает, заключается в том, что предполагается, что каждый тип сообщения принадлежит («принадлежит») только одной логической услуге.

От имени ваших издателей я предполагаю, что они одинаковы - то есть, что они являются двумя экземплярами одной и той же логической службы, а это означает, что вы можете легко достичь того, что вам нужно, разрешив им делиться подпиской хранение - например в общем SQL Server.

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

PS: Хорошо найти с лесозаготовительной вещью - я создал an issue и это будет исправлено в ближайшее время;)

PPS: Обновление о регистрации вещи - теперь я помню, что Ребус намеренно не регистрирует ошибку во время настройки - рассуждение заключается в том, что ведение журнала выполняется только для исключений, которые не отображаются на вызывающем абоненте, потому что вы сможете поймать другие исключения и делать то, что, по вашему мнению, должно быть сделано с ними.