-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DirectMessageListenerContainer fails to recover consuming after node fail #1034
Comments
@bendyna Is there anything in the log after the I can't reproduce it (using a real cluster on hardware, not docker). I see the consumer monitor thread detecting the dead consumer and starting a new one. The With trace level logging, I see this...
|
Trace logs:
and this last line ("... channel.isOpen()") logged infinitely every 5 seconds |
That's bizarre - it implies the channel is reporting that it is open; not sure how that can happen but I will add some code to use the failure to nack as an alternative signal that the consumer is dead. |
Resolves spring-projects#1034 The monitor task now cancels the consumer after a failed ack/nack, whether or not the channel `isOpen()` returns true. Test with a mock channel that stays open after a failed ack. **cherry-pick to 2.1.x, 2.0.x**
Resolves #1034 The monitor task now cancels the consumer after a failed ack/nack, whether or not the channel `isOpen()` returns true. Test with a mock channel that stays open after a failed ack. **cherry-pick to 2.1.x, 2.0.x**
Resolves #1034 The monitor task now cancels the consumer after a failed ack/nack, whether or not the channel `isOpen()` returns true. Test with a mock channel that stays open after a failed ack. **cherry-pick to 2.1.x, 2.0.x** * Fix tests removing AssertJ dependency
Resolves #1034 The monitor task now cancels the consumer after a failed ack/nack, whether or not the channel `isOpen()` returns true. Test with a mock channel that stays open after a failed ack. **cherry-pick to 2.1.x, 2.0.x** * Fix tests removing AssertJ dependency
@garyrussell it fixes issue with ack, but problem is more common As I understand it, DMLC creates channel with CachingConnectionFactory. But it's not real channel, it is proxy channel, which has real channel inside (field "target"). But proxy channel can replace target, and DMLC does not know about it. DMLC "thinks" that it is the same channel, and checks if it is open in method checkConsumers(). And this new channel is open, but basicConsume was not sent to this new channel. You fixed case with ack, but it's also possible to reproduce it with nack.
I set larger container intervals for reproducibility. Log:
I think, DMLC should somehow monitor if target channel was recreated in proxy, and restart consumer in this case. |
Good point. |
Fixes spring-projects#1034 If the connection factory refreshed the target connection, the DMLC is not made aware of it and so we never consume from the new channel. **cherry-pick to all 2.x**
Fixes spring-projects#1034 If the connection factory refreshed the target connection, the DMLC is not made aware of it and so we never consume from the new channel. **cherry-pick to all 2.x**
Fixes #1034 If the connection factory refreshed the target connection, the DMLC is not made aware of it and so we never consume from the new channel. **cherry-pick to all 2.x**
Fixes #1034 If the connection factory refreshed the target connection, the DMLC is not made aware of it and so we never consume from the new channel. **cherry-pick to all 2.x** # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/listener/DirectMessageListenerContainerMockTests.java
Fixes #1034 If the connection factory refreshed the target connection, the DMLC is not made aware of it and so we never consume from the new channel. **cherry-pick to all 2.x** # Conflicts: # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/listener/DirectMessageListenerContainerMockTests.java # Conflicts: # spring-rabbit/src/main/java/org/springframework/amqp/rabbit/listener/DirectMessageListenerContainer.java # spring-rabbit/src/test/java/org/springframework/amqp/rabbit/listener/DirectMessageListenerContainerMockTests.java
Version 2.1.7.RELEASE
If node in RabbitMQ cluster fails, DirectMessageListenerContainer does not reconnect to other node. Docker containers, where I could reproduce it, attached.
docker.zip
pom.xml
Application.java
Steps to reproduce (with docker):
I tried this 10 times and in 7 times out of 10 DMLC was unable to continue consuming. Log:
3 times out of 10 DMLC reconnected and recovered consuming. Log:
Also tried same steps 10 times with SimpleMessageListenerContainer. All 10 times SMLC recovered consuming.
The text was updated successfully, but these errors were encountered: