`StreamMessageListenerContainer` should wait until listeners finish processing within timeout during shutdown

[lrozek]

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

[mp911de]

Thanks for raising the topic. It makes sense to await completion in the stop method to avoid any races or connection errors because the connection is closed while still in use.

[lrozek]

@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.

[lrozek]

@mp911de I reported relevant race conditions in #2262

[MrNocTV]

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.
Cant find any workaround at the moment :(
With this bug I don't think spring-data-redis is production ready.

[aooohan]

@mp911de Hi, I have tried to fix this issue. Please review #2563, let me if any improvement need do.

[tubbynl]

not really a race condition because it always happens on shutdown, the racing part perhaps is that the connections are closed before the StreamMessageListenerContainer

only "solution" currently is to disable the logger to prevent the exceptions spamming the logs / alerting.

logging.level.org.springframework.data.redis.stream=off

perhaps a half-way solution would be to let Subscription implement Lifecycle and close it if he's the last listener.
scratch that, he is not aware if it's container