channel.open timeout

[wangdonghello]

com.rabbitmq.client.ChannelContinuationTimeoutException: Continuation call for method #method<channel.open>(out-of-band=)on channel AMQChannel (amqp://xxx@ip:5672/xxx,4)(#4) time out
at com.rabbitmq.client.impl.AMQChannel.wrapTimeoutException(AMQChannel.java:308)
.........

channel.open the number 4 often fail

[michaelklishin]

I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :(

[michaelklishin]

We don't have much information to work with here but this timeout is client-side and can be increased. The default in modern versions is substantial, though (10 minutes). See server logs for any potential clues such as channel exceptions, and runtime metrics for signs of possible CPU resource starvation.

[wangdonghello]

Caused by: com.rabbitmq.client.ChannelContinuationTimeoutException: Continuation call for method #method<channel.open>(out-of-band=) on channel AMQChannel(amqp://xxx@ip:5672/xxx,4) (#4) timed out
at com.rabbitmq.client.impl.AMQChannel.wrapTimeoutException(AMQChannel.java:308)
at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:290)
at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:138)
at com.rabbitmq.client.impl.ChannelN.open(ChannelN.java:133)
at com.rabbitmq.client.impl.ChannelManager.createChannel(ChannelManager.java:176)
at com.rabbitmq.client.impl.AMQConnection.createChannel(AMQConnection.java:553)
at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.createChannel(AutorecoveringConnection.java:165)
at org.springframework.amqp.rabbit.connection.SimpleConnection.createChannel(SimpleConnection.java:57)
... 204 common frames omitted
Caused by: java.util.concurrent.TimeoutException: null
at com.rabbitmq.utility.BlockingCell.get(BlockingCell.java:77)
at com.rabbitmq.utility.BlockingCell.uninterruptibleGet(BlockingCell.java:120)
at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:36)
at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:494)
at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:288)
... 210 common frames omitted

[wangdonghello]

This is all the exception information，
Thank you for your reply。

[michaelklishin]

I now see this is for channel.open. Then I'd see if the connection may be publishing and blocked by a resource alarm. One possible scenario for that is applications leaking channels.

[wangdonghello]

There are plenty of machines resource

[vishalbasra]

running into this as well - no apparent resource contention - channel churn is also normal
on version 3.8.14

[michaelklishin]

A short lived (say, a minute) resource alarm or internal flow control can result in a channel operation timeout for some clients that use defaults that are lower than 60s. Operation timeouts is a sad fact of life in distributed systems.

[michaelklishin]

Until evidence of something specific that has to change in the client emerges, we assume this regular dist sys operations "noise". Applications should be developed with possible operation timeouts in mind. Channel churn, resource alarms (even lasting for a minute) and CPU pressure on the node all should be considered when investigating channel operation timeouts (worth mentioning that connection timeouts is a whole separate can of worms).