We use spring boot with embedded netty server that has graceful shutdown (that seems has been fixed in https://github.com/spring-projects/spring-framework/issues/23631) and do some logic using another beans autowired into controller. When sigterm is received server waits for all in-progress requests are finished, and we have case when service is destroyed before request is finished and requests are failed due to closed resources in destroy method. and as I can see reactorServerResourceFactory is always destroyed last. So would be great to have ability to set up ordering between reactorServerResourceFactory and custom beans. Or probably do we have a way already to customize this bean to have @DependsOn annotation with dependency on our beans?

SpringBoot version: 2.2.2.RELEASE

Comment From: wilkinsona

Duplicates #4657.

Comment From: LychakGalina

@wilkinsona there are too many issues raised in https://github.com/spring-projects/spring-boot/issues/4657, and more about how to prevent accepting new requests/implement custom graceful shutdown with serverCustomizer interface for tomcat/jetty/completion all active requests, but currently waiting for active requests when sigterm is received works for Netty, doesn't it? and do we really have no way to customize reactorServerResourceFactory to have something like @DependsOn?

Comment From: wilkinsona

more about how to prevent accepting new requests/implement custom graceful shutdown with serverCustomizer interface for tomcat/jetty/completion all active requests

The customizer approach is a way of someone implementing their own solution until Spring Boot supports it out-of-the box. #4657 is tracking the addition of that support.

but currently waiting for active requests when sigterm is received works for Netty, doesn't it?

I don't believe so, not out of the box anyway.

do we really have no way to customize reactorServerResourceFactory to have something like @DependsOn?

You can use a BeanFactoryPostProcessor to set up custom depends on configuration. Once #4657 is implemented it, hopefully, will not be necessary as the web server should stop accepting new requests, wait for any inflight requests to complete, and then allow closing of the context to proceed.

Comment From: LychakGalina

I don't believe so, not out of the box anyway.

it's strange, have tested this in a simple way - add Thread#sleep to endpoint, call endpoint, and send sigterm to application, it doesn't destroy the webServer bean until request is finished. and it didn't work before this issue is fixed https://github.com/spring-projects/spring-framework/issues/23631

Comment From: wilkinsona

There's more to it than that. As described in #4657 we currently close the application context and then, at the end of that, close the web server. This means that beans that an inflight request relies upon may be destroyed while the request is still being handled. We need to do three things:

  1. Stop any new requests from being accepted
  2. Wait for any existing requests to complete
  3. Close the application context

We're now going over things that have been discussed at length and are being tracked by #4657. Please subscribe to that issue for further updates.

Comment From: LychakGalina

We need to do three things:

it's clear, thanks but my point was that one of these things (wait for any existing requests to complete) already works for us when we use EmbeddedNetty server, and it didn't until we upgraded springBoot/springFramework from 2.0.5/5.0.9 -> 2.2.2/5.2.2