Prevent high channel churn in a queue full scenario#9181
Merged
oscerd merged 2 commits intoapache:camel-3.20.xfrom Jan 24, 2023
Merged
Prevent high channel churn in a queue full scenario#9181oscerd merged 2 commits intoapache:camel-3.20.xfrom
oscerd merged 2 commits intoapache:camel-3.20.xfrom
Conversation
In a scenario with a high message publishing rate and a full queue the publisher will get "nack" (not acknowledged) as feedback from RabbitMQ. The method Channel#waitForConfirmsOrDie(long) in https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ChannelN.java#L241 will close the channel. This closed channel is then given back to the channel pool. Next time the channel is taken out of the pool it is detected as closed and will be removed. So a new channel needs to be opened and this too will be closed directly after usage when the same queue is still full. There will be a high rate of opened and closed communication channels and the channel pool gets unusable. This is described as high channel churn (https://www.rabbitmq.com/channels.html#high-channel-churn) and can have side effects on RabbitMQ (memory and cpu resource usage) and performance too. It was also discussed with folks from rabbitmq-java-client (rabbitmq/rabbitmq-java-client#942) and the usage of Channel#waitForConfirmsOrDie(long) is "highly NOT recommended" by them. This behavior affects ALL versions of the camel-rabbitmq component!
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 If necessary Apache Camel Committers may access logs and test results in the job summaries! |
Contributor
|
Please don't close this one, this is a bug, so it should go on 3.20.x too, thanks. |
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 If necessary Apache Camel Committers may access logs and test results in the job summaries! |
davsclaus
approved these changes
Jan 22, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In a scenario with a high message publishing rate and a full queue the publisher will get "nack" (not acknowledged) as feedback from RabbitMQ.
The method
Channel#waitForConfirmsOrDie(long)in https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ChannelN.java#L241 will close the channel. This closed channel is then given back to the channel pool. Next time the channel is taken out of the pool it is detected as closed and will be removed. So a new channel needs to be opened and this too will be closed directly after usage when the same queue is still full. There will be a high rate of opened and closed communication channels and the channel pool gets unusable.This is described as high channel churn (https://www.rabbitmq.com/channels.html#high-channel-churn) and can have side effects on RabbitMQ (memory and cpu resource usage) and performance too.
It was also discussed with folks from rabbitmq-java-client (rabbitmq/rabbitmq-java-client#942) and the usage of Channel#waitForConfirmsOrDie(long) is "highly NOT recommended" by them.
This behavior affects ALL versions of the camel-rabbitmq component!