Closing RabbitChannel takes too much time.

[ElAdriano]

Hello, my question is related to this channel close logic.

I wonder why it's necessary to wait 10 seconds for it to be closed. As I understand the implemented flow - actual channel close is done here. Then, why it's necessary to wait so much time?

Is there any way to skip this (and not lose on performance)?
Thank You for help in advance :)

[michaelklishin]

@ElAdriano closing a channel is a network roundtrip. There is no additional delay enforced in the protocol (something akin to the TIME_WAIT state in TCP).

I can see how closing a channel could take 10s on a very busy or blocked connection.

If you open and close channels at a high rate, I'm afraid you have lost massively "on performance" to begin with. A round-trip to the server cannot be avoided (it must close its side of the channel, too, not doing so is a resource leak). You simply cannot beat using long-lived channels, the way the protocol expects them to be used.

[michaelklishin]

Oh, this delay in the .NET client specifically is news to me.

I don't know why it does that. Other clients do not. Given the ongoing on work on making this client as async as practically possible, I'd not be surprised if that goes away by 8.0.

[lukebakken]

@ElAdriano the code to which you linked waits a maximum of 10 seconds for the close response from the server. In normal scenarios, the wait time is in the low millisecond range.

If you consistently hit the 10 second wait in your environment, then you have an issue in your environment preventing the Close.Ok frame from RabbitMQ reaching your application in a timely manner.

[michaelklishin]

@ElAdriano to clarify this slightly, resource alarms on the target RabbitMQ node is the most likely scenario. They will be very visible in the logs. Very.