Large number of Retries

, ,
1

We have an issue where sending messages (ICommand) via a simple Send command generates a lot of retries. The retries are caused by System.InvalidOperationException: No handlers could be found for message type: <…> at NServiceBus.LoadHandlersConnector.d__1.MoveNext() in C:\BuildAgent\work\ed946b9f0e4aae01\src\NServiceBus.Core\Pipeline\Incoming\LoadHandlersConnector.cs:line 35

Eventually all the messages get processed as long the number of delayed retries is high enough. These info/warning messages are the same as when I stop the handler service altogether, except, of course, if the service is stopped the messages would eventually fail to process and get moved into the error queue.

I am wondering if we are missing certain configuration or the service/endpoints are not wired correctly. The number of retries needed for the messages to get through the system, does seem to depend on how busy the system is and how long does one handler needs to process the message (most of it are database insert/update operations). We are using NServiceBus 4.7.2 and SqlServer as the Transport type.

Thanks

2

This topic got bumped up for some reason. I hope you’ve figured it out by now? And otherwise this reply is for anyone reading this that has the same issue.

It’s likely that you have competing consumers of two different endpoints.

image
image835×584 13.7 KB

So the above image shows two actually competing consumers, ReceiverA. It exists twice and they both compete for messages. They both have a handler for the message they’re expecting.

However ReceiverB is also reading from the same queue and it doesn’t have the message handler! :frowning: This means that it will continuously get the error you’re seeing, until an instance of ReceiverA picks it up. That’s what you’re seeing, that if it’s being retried enough times, at some point ReceiverA will pick it up and the message will no longer be picked up by ReceiverB.

This can either happen

  1. when you’ve given two logically different endpoints the same name
  2. when you’ve specified where the input queue is for an endpoint.
  3. Perhaps doing something else, like using unique instances or something, although I can’t imagine this being it.

Hope this helps