-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
StreamMessageListenerContainer
should wait until listeners finish processing within timeout during shutdown
#2261
Comments
StreamMessageListenerContainer
should wait until listeners finish processing within timeout during shutdown
Thanks for raising the topic. It makes sense to await completion in the |
@mp911de the point was rather to allow graceful shutdown of redis listener to finish its processing instead of terminating abruptly, which could lead to data being lost or corrupted. Races and connections errors that you mentioned I also encountered during shutdown, however I intended to report it as a separate issue. |
Hi, I have the same problem with @lrozek that also posted here on stackoverflow. https://stackoverflow.com/questions/74003013/spring-boot-web-socket-message-broker-shutdown-before-redis-stream It's kinda similar. The application needs to process all remaining messages and only then terminated. |
when spring boot application is being shutdown gracefully, DefaultStreamMessageListenerContainer should wait until listeners have finished their processing within given timeout. Currently redis stream listeners are terminated instantly in the middle of the listener handler without giving them a chance to finish
Similar functionality is offered for RabbitMQ listeners (https://github.com/spring-projects/spring-amqp/blob/main/spring-rabbit/src/main/java/org/springframework/amqp/rabbit/listener/SimpleMessageListenerContainer.java#L634) and JMS listeners (https://www.amitph.com/spring-boot-graceful-shutdown/#JMS_Listener)
repro project can be found here https://github.com/lrozek/redis-listener-graceful-shutdown
The text was updated successfully, but these errors were encountered: