Lost messages when using RabbitMQ transport

[Zehelein]

Hi,

I am building a spike solution based on the NServiceBus tutorial https://docs.particular.net/tutorials/nservicebus-step-by-step/1-getting-started/ to see how to build it with your library.

I managed to get to step three to have two services - one "client ui" one to send a command and a "sales" endpoint to receive it. This works - the command is sent and it is also received. But every few messages

I added a bit of simple log output that shows up like that:

Sending a place order with ID 19754292-9500-4184-b1bb-5a187cacecde.
Sending a place order with ID 0e754bb1-079b-45cb-bdda-32d508c133cd.
Sending a place order with ID e86d99db-5870-4f60-9cd5-5c9edfb8d803.
2020-03-02T13:36:14.867Z warn:  No handlers were registered for message. This could mean that either the handlers haven't been registered with bootstrap.registerHandler(), or that the underlying transport is subscribed to messages that aren't handled and should be removed. {
  "name": "HandlerRegistry",
  "receivedMessage": {
    "orderId": "e86d99db-5870-4f60-9cd5-5c9edfb8d803",
    "$name": "service-bus-spike/place-order",
    "$version": 0
  }
}
2020-03-02T13:36:14.879Z warn:  No handlers registered for message. Message will be discarded { 
  "name": "ServiceBus",
  "messageType": {
    "orderId": "e86d99db-5870-4f60-9cd5-5c9edfb8d803",
    "$name": "service-bus-spike/place-order",
    "$version": 0
  }
}

The second endpoint logs the received message - and the e86d... one is missing:

2020-03-02T13:36:12.853Z info:  Received place order command with ID 19754292-9500-4184-b1bb-5a187cacecde {
  "name": "PlaceOrderHandler"
}
2020-03-02T13:36:13.864Z info:  Received place order command with ID 0e754bb1-079b-45cb-bdda-32d508c133cd {
  "name": "PlaceOrderHandler"
}
2020-03-02T13:36:15.874Z info:  Received place order command with ID 9a85e0c8-04f6-4b63-a692-8c126c8a67d5 {
  "name": "PlaceOrderHandler"
}

Do you have an idea what could potentially be the issue? I uploaded my current super simple solution here if that helps: https://github.com/Zehelein/service-bus-spike

And if I start up the client-ui without first starting the consumer (= sales) application first I get the rejected messages all of the time:

Sending a place order with ID 7b9b9e13-00ad-43da-b949-02aa95b758f3.
2020-03-02T14:00:40.584Z warn:  No handlers were registered for message. This could mean that either the handlers haven't been registered with bootstrap.registerHandler(), or that the underlying transport is subscribed to messages that aren't handled and should be removed. {
  "name": "HandlerRegistry",
  "receivedMessage": {
    "orderId": "7b9b9e13-00ad-43da-b949-02aa95b758f3",
    "$name": "service-bus-spike/place-order",
    "$version": 0
  }
}
2020-03-02T14:00:40.595Z warn:  No handlers registered for message. Message will be discarded { 
  "name": "ServiceBus",
  "messageType": {
    "orderId": "7b9b9e13-00ad-43da-b949-02aa95b758f3",
    "$name": "service-bus-spike/place-order",
    "$version": 0
  }
}

[Zehelein]

Ok I checked a bit more on the code level. It seems the service-bus.ts tries to handle the message.

          await this.dispatchMessageToHandlers(message.domainMessage, message.attributes)
          this.logger.debug('Message dispatched to all handlers', { message })
          await this.transport.deleteMessage(message)

And even if there is no handler registered for that message it still tries to read the message, forward it to no existing handlers (in this node) and then delete the message.

Am I missing something? In NServiceBus there would be named endpoints and commands would go to exactly that endpoint with the name. Others would not read this message.

[Zehelein]

Ok - found it. I need to use a different queue name in the const rabbitConfiguration: RabbitMqTransportConfiguration = {...}. Then it works nicely.

I will continue further but maybe there could be more documentation or some step-by-step guide or example project on how to setup distributed messaging :-)

[adenhertog]

Hi @Zehelein,

You beat me to it :) By the look of the initial implementation, both the frontend and backend services were connected and reading from the same queue. The reason why messages were disappearing is that when the frontend service read a message first, it would discard it immediately as it didn't have any registered handlers for it.

I agree that documentation could be improved regarding the integration of all the different components. I'll add a task to help improve that.

Thanks for the feedback

[Zehelein]

Thanks for looking into it and your fast follow up! 😃