Messaggi mancanti del listener NServiceBus

Question

Ho appena iniziato a giocare con nservice bus e sto cercando di far funzionare la pubblicazione. Ho un ascoltatore che sembra mancare alcuni messaggi. È configurato con

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

È interessante notare che se imposto NumberOfWorkerThreads su 1 manca costantemente ogni altro messaggio. Per valori più grandi sembra meno determinato. Nel mio gestore di messaggi ho

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; }
    }
}

e il bus è configurato con

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

C'è qualcosa che devo fare e la fine del Gestore in modo tale da essere liberato pronto a ricevere il messaggio successivo o qualche configurazione che devo fare in modo che ci sia una coda sul lato client per conservare i messaggi se il gestore è occupato. Il tempo che intercorre tra l'invio dei messaggi non sembra avere importanza, potrebbero essere 20 secondi e l'ascoltatore continua a non ricevere tutti i messaggi.

Answer 1

Dopo aver dato un'occhiata alla soluzione che hai inviato, vedo qual è il problema.

Hai specificato la stessa coda di input per entrambi i processi: l'editore e l'abbonato. Di conseguenza, hai entrambi i processi in lotta per i messaggi che (penso) intendi indirizzare solo al sottoscrittore.

Dai a ogni processo la sua coda di input e tutto dovrebbe andare bene con il mondo :-)

Answer 2

Se stai lavorando in modo simile al pub / sottocampione, quello che potresti vedere è "quotazioni polimorfiche".

Nel pub / sub esempio, l'editore pubblica alternativamente un'interfaccia IEvent e una classe concreta EventMessage (che eredita IEvent).

Se un abbonato è iscritto alla classe concreta, non riceverà i messaggi di interfaccia. Questo vale per tutti i tipi di gerarchie, se ti iscrivi alla classe specifica e l'editore pubblica un messaggio del tipo della sua classe base, il messaggio non verrà inviato.

Le sottoscrizioni polimorfiche funzionano al contrario. Se ti iscrivi alla base, arriverà qualsiasi sottoclasse pubblicata dall'editore.

Questo non ha nulla a che fare con il threading.

Spero che sia d'aiuto.