Endless loop when bus had been stopped while transport is trying to reconnect about nservicebus.rabbitmq

[SzymonPobiega]

Hi

Thanks for raising the issue. Does removing the critical action handler constitute a viable workaround for you? The NServiceBus transports have been designed to handle connection issues in a graceful manner so just removing the critical action handler should be fine. The transport will not consume significant resources while trying to re-connect.

In the meantime we'll look into how we could fix the underlying problem.

[mstavrev]

Hello,

This is a partial way to deal with the problem, but not entirely. We are bringing up and down endpoints depending on some business logic. E.g. the life-time of endpoints do not coincide with the life-time of the hosting process.
Because of that, it is possible for a broker to becomes inaccessible before our logic no longer needs to work with it and stop the endpoint. That means the endless loop (causing high CPU usage) may be still triggered. The only "work-around" would be not to stop a no longer needed endpoint, but instead leaving it dangling (having its pump operating in the background). That however, may lead to other problems, as if the broker becomes eventually online the endpoint may restore message consumption where this is no longer intended.

I understand the concept of NServiceBus is more towards decomposing the workload on separate, independent, self-hosted bus-oriented instances, where such an error ideally would terminate the hosting process. However, it isn't something we can go for at the moment.

[SzymonPobiega]

OK, thanks for the explanation.

[SzymonPobiega]

@mstavrev could you also open a support case with us so that we have a private channel to discuss anything sensitive?

[ramonsmits]

@mstavrev This is a duplicate of #1186 for which we are releasing a patch release.