Provide a constant for graceful shutdown's smart lifecycle phase

[joca-bt]

Upon graceful shutdown the application will wait for a configurable timeout before killing the webserver and continuing with the termination of the rest of the application. Graceful shutdown is currently happening after ContextClosedEvent is published and before beans are destroyed, during lifecycle stop.

Our application publishes information about all serviced requests to an external data source. We're typically not interested in the requests that were terminated inflight by the graceful shutdown but are interested in the ones that finished after the shutdown was triggered. The logger publishing this information is async and we would like to flush it after the webserver has finished servicing all live requests and has been terminated and only then terminate the logger.

Currently we can achieve this with a SmartLifecycle bean whose phase is later than that of bean webServerGracefulShutdown. Bean webServerGracefulShutdown has the default phase but this is not documented and the class is not public, so this feels a bit hacky. Alternatively, we could terminate our logger on ContextClosedEvent. However, this way we would be dropping the logging of all the requests that finished being serviced during graceful shutdown.

There's a WebServerInitializedEvent. Would having a similar event for termination make sense?

I think @PreDestroy would also be an option but I'm not sure it might be the desired interface in this or similar situations.

[snicoll]

This is discussing a possible enhancement. The guide isn't clear on how to tag the issue type - to make it clear this is not a bug report.

There are many different types of issue that can be reported: bug report, feature request but also documentation glitch or missing section in the release notes on the Wiki. The TL;DR is that you don't have to tag anything and the team will triage the issue when time permits.

[philwebb]

We're not sure about adding a new event, but we do want to improve the documentation and perhaps add some constants so that things are clearer.

[philwebb]

Putting the constants on WebServerGracefulShutdownLifecycle would be an option if we make the class public but keep the constructor package-private. We'd also make the class final.

[wilkinsona]

We've got two smart lifecycle classes at the moment:

• org.springframework.boot.web.reactive.context.WebServerGracefulShutdownLifecycle
• org.springframework.boot.web.servlet.context.WebServerGracefulShutdownLifecycle

It might be a bit confusing to have a constant defined on both of them. The alternative would be a common smart lifecycle in org.springframework.boot.context that can be used with the reactive and servlet-based code. This would, however, require the constructor to be public. Here's what that looks like.

We were keen to keep the constructors package-private. Flagging for team attention to see if we'd rather keep the separate smart lifecycles with package-private constructors and have two constants, or a single smart lifecycle and constant but with a public constructor.

[philwebb]

I like the single class, it seems less confusing than duplicated constants.