You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the application starts, a message is sent to another service. During the start, the Rabbitmq broker crashed and the application began to write endlessly to the log line until it ran out of disk space. The line was written to the log is DEBUG(org.springframework.amqp.rabbit.listener.DirectReplyToMessageListenerContainer): Consume from queue amq.rabbitmq.reply-to ignore, container stopping
To Reproduce
Unfortunately, this problem has occurred twice in half a year and I can't say for sure how it can be reproduced. But as far as I understand, this happens in the method DirectMessageListenerContainer#adjustConsumers in the method inside the loop while (this.consumersByQueue.get(queue) == null || this.consumersByQueue.get(queue).size() < newCount) . If we put a breakpoint there and set the container (this.active == false), then we are stuck in an endless loop.
Expected behavior
If the container is not active, then as far as I understand, we should not try to specify the number of consumers. At least in this situation, the thread should not hang in an endless loop.
The text was updated successfully, but these errors were encountered:
Yeah, totally agreed on the problem.
So, when we enter this loop, we exit immediately from the doConsumeFromQueue:
private void doConsumeFromQueue(String queue, int index) {
if (!isActive()) {
if (this.logger.isDebugEnabled()) {
this.logger.debug("Consume from queue " + queue + " ignore, container stopping");
}
return;
}
And since we don't "really adjust" those consumers, we come back to the beginning of that while().
I guess we need to fix it like this:
while (isActive() && ...
To check for working state on every iteration.
Note: the version 2.4.x is out of Open Source support: https://spring.io/projects/spring-amqp#support.
So, even if we fix it, it is not going to make to that version.
Therefore you need to start thinking about upgrading your solution to newer versions of Spring projects.
Fixes: #2760
When the application starts, a message is sent to another service.
During the start, the Rabbitmq broker crashed and the application began to write endlessly to the log line until it ran out of disk space.
The line was written to the log is `DEBUG(org.springframework.amqp.rabbit.listener.DirectReplyToMessageListenerContainer): Consume from queue amq.rabbitmq.reply-to ignore, container stopping`
(cherry picked from commit dd6a171)
Version: 2.4.17
Describe the bug
When the application starts, a message is sent to another service. During the start, the Rabbitmq broker crashed and the application began to write endlessly to the log line until it ran out of disk space. The line was written to the log is
DEBUG(org.springframework.amqp.rabbit.listener.DirectReplyToMessageListenerContainer): Consume from queue amq.rabbitmq.reply-to ignore, container stopping
To Reproduce
Unfortunately, this problem has occurred twice in half a year and I can't say for sure how it can be reproduced. But as far as I understand, this happens in the method
DirectMessageListenerContainer#adjustConsumers
in the method inside the loopwhile (this.consumersByQueue.get(queue) == null || this.consumersByQueue.get(queue).size() < newCount)
. If we put a breakpoint there and set the container (this.active == false
), then we are stuck in an endless loop.Expected behavior
If the container is not active, then as far as I understand, we should not try to specify the number of consumers. At least in this situation, the thread should not hang in an endless loop.
The text was updated successfully, but these errors were encountered: