spring-cloud
Alling getPhase() with Updated Phases for Graceful Shutdown
https://github.com/spring-cloud/spring-cloud-stream/blob/e14bc1cb51cb4475dfe054b91b7f6ba6a4441be1/core/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/binding/InputBindingLifecycle.java#L52
According to https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#updated-phases-for-graceful-shutdown:
Updated Phases for Graceful Shutdown
The phases used by the SmartLifecycle implementations for graceful shutdown have been updated. Graceful shutdown now begins in phase SmartLifecycle.DEFAULT_PHASE - 2048 and the web server is stopped in phase SmartLifecycle.DEFAULT_PHASE - 1024. Any SmartLifecycle implementations that were participating in graceful shutdown should be updated accordingly.
getPhase() for classes InputBindingLifecycle, OutputBindingLifecycle should be aligned too so graceful shutdown is working as excepted
I tested the proposed solution, and it doesn't work. In our project, the web server receives an HTTP request and converts it into a message. This message is sent via Spring Cloud Stream and RabbitMQ to other services for processing. Meanwhile, the request waits on the web server for a response. Once the message is processed, the waiting request is retrieved, and the response to the HTTP request is sent.
In this case, it's necessary to perform a graceful shutdown of the web server first, followed by a graceful shutdown of the Spring Stream. This ensures that the web server stops accepting requests while the streams have enough time to finish processing all pending requests. Therefore, the getPhase method must return a value smaller than Integer.MAX_VALUE - 2048, such as Integer.MAX_VALUE - 3000.
It would be best if you create a small reproducible sample. Meanwhile I'll update InputBindingLifecycle to SmartLifecycle.DEFAULT_PHASE - 3000;
@olegz olegz Should this value be made configurable for both OutputBindingLifecycle and InputBindingLifecycle?
Having sensible defaults is great, but it would be even better to allow users to customize the lifecycle order.
In my case, for example, I would like to stop incoming messages as soon as possible — there's no need to wait for the web server to shut down. However, for output, I need it to stop after the web server, since requests might still generate new messages to send.
