Обработчик сообщений не активируется

Question

У меня возникли проблемы с ребусом.

Вот мой сценарий. У нас есть три услуги

Идентичность) опубликованных сообщений 'IdentityCreated'

шлюз) посылает 'UpdateProfileCommand' непосредственно в 'Профиль-westeu-вход' очереди

Профиль) Потребляет сообщения из входной очереди «profile-westeu-input» и подписывается на сообщения «IdentityCreated»

Конфигурация ребуса видна в Служба профилей

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

container.Register(Classes.FromThisAssembly() 
        .BasedOn(typeof(IHandleMessages<>)) 
        .WithServiceAllInterfaces() 
        .LifestyleTransient()); 

И я настроен с

Головоломки

var bus = Configure.With(new CastleWindsorContainerAdapter(container)) 
      .Logging(x => x.Trace()) 
      .Transport(
       t => t.UseAzureServiceBus(connectionStringNameOrConnectionString: connectionString, 
         inputQueueAddress: ProfileInputQueueName, mode: AzureServiceBusMode.Standard)) 
      .Options(o => o.SimpleRetryStrategy(ProfileErrorQueueName)) 
      .Start(); 

и подписался на тип сообщения, как этот

bus.Subscribe(typeof(Nabufit.Messages.Identity.Events.IdentityCreated)).Wait() 

я ожидал мой обработчик был вызывается автоматически. Однако оно не :(.

Я пробовал различные решения

• Измененное название входных очередей
• Создал программу EventEmitter, который опубликовал событие типа «IdentityCreated». При поиске в входной очереди он присутствует, но это не получить подобран ребус

Bonus информация:.

• Использования лазурного автобус службы
• хостинга Головоломки внутри приложения Service ткани
• Моей очереди ввода с именем «Профиль-westeu-входом»

Answer 1

После изучения заявки мы обнаружили, что мы разделили наш Виндзорский Container между нашим Webapi в OwinCommunicationListener, у которого была определенная конфигурация зависимостей времени жизни. Это вызвало две разные ошибки.

1. Ребуса не подобрать события, из-за конфигурации контейнеров
2. Architectural мудрого это не смарт обмена такой же контейнер с процессом потребляющего

Мы в конечном итоге построением пользовательского ICommunicationListener конкретным для используя процесс сборки с использованием встроенного класса BuiltinHandlerActivation с ребусом. чтобы выглядеть примерно так.

public class ServiceBusCommunicationListener : ICommunicationListener 
{ 
    private BuiltinHandlerActivator activator; 

    public async Task<string> OpenAsync(CancellationToken cancellationToken) 
    { 
     activator = new BuiltinHandlerActivator(); 
     RegisterHandlers(activator); 

     var connectionString = "..."; 
     var bus = Configure.With(activator) 
      .Logging(x => x.Serilog(Log.Logger)) 
      .Transport(
       t => t.UseAzureServiceBus(connectionStringNameOrConnectionString: connectionString, 
         inputQueueAddress: "input", mode: AzureServiceBusMode.Standard)) 
      .Options(o => o.SimpleRetryStrategy("error")) 
      .Start(); 

     return connectionString; 
    } 

    private void RegisterHandlers(BuiltinHandlerActivator builtinHandlerActivator) 
    { 
     (...) 
    } 

    public async Task CloseAsync(CancellationToken cancellationToken) 
    { 
     if (activator != null) 
      activator.Dispose(); 
    } 

    public void Abort() 
    { 
     if (activator != null) 
      activator.Dispose(); 
    } 
} 

И регистрировать ServicebusCommunicationListner как ServiceInstanceListener.

internal sealed class ProfileService : StatelessService 
{ 
    public ProfileService(StatelessServiceContext context) 
     : base(context) 
    { } 

    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners() 
    { 
     return new[] 
     { 
      new ServiceInstanceListener(context => new ServiceBusCommunicationListener()), 
     }; 
    } 
}