Слушатель NServiceBus Пропущенные сообщения

Question

Я только начинаю играть с автобусом nservice и пытаюсь получить публикацию. У меня есть слушатель, который, кажется, пропускает некоторые сообщения. Он настраивается с

<MsmqTransportConfig 
    InputQueue="InformMessages" 
    ErrorQueue="error" 
    NumberOfWorkerThreads="5" 
    MaxRetries="5" 
/> 

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

class MessageHandler : IMessageHandler<ICourseRegister> 
{ 
    public void Handle(ICourseRegister message) 
    { 
     Console.WriteLine("Message dun got gotted"); 
     Console.WriteLine("Course name is: " + message.CourseName); 
    } 

    private IBus bus; 
    public IBus Bus 
    { 
     set { this.bus = value; } 
    } 
} 

и шины сконфигурирован с

 var bus = NServiceBus.Configure.With() 
       .SpringBuilder() 
       .XmlSerializer() 
       .MsmqTransport() 
        .IsTransactional(true) 
        .PurgeOnStartup(false) 
       .UnicastBus() 
        .ImpersonateSender(false) 
        .LoadMessageHandlers() 
       .CreateBus() 
       .Start(); 

Есть ли что-то мне нужно делать, и конец Handler таким образом, что он освобождается готов к приему следующего сообщения или в какой-то конфигурации мне нужно сделать так, чтобы на стороне клиента стояла очередь, чтобы сохранить сообщения, если обработчик занят. Время между отправкой сообщений, похоже, не имеет значения, это может быть 20 секунд, и слушатель все равно не получает все сообщения.

Answer 1

После ознакомления с решением, которое вы отправили, я вижу, в чем проблема.

Вы указали одну и ту же входную очередь для обоих процессов - издателя и подписчика. В результате у вас есть оба процесса, борющихся за сообщения, которые (я думаю) вы намерены делать только для подписчика.

Дайте каждому процессу собственную очередь ввода, и все должно быть правильно с миром :-)

Answer 2

Если вы работаете аналогично паб/sub sample, то, что вы могли видеть, это «полиморфные подписки».

В публикации pub/sub, издатель поочередно публикует интерфейс IEvent и конкретный класс EventMessage (который наследует IEvent).

Если абонент подписан на конкретный класс, он не получит сообщения интерфейса. Это верно для всех типов иерархий, если вы подписываетесь на определенный класс, и издатель публикует сообщение о типе своего базового класса, сообщение не будет отправлено.

Полиморфные подписки работают наоборот. Если вы подписаны на базу, любой подкласс, который публикует издатель, прибудет.

Это не имеет ничего общего с резьбой.

Надеюсь, что это поможет.