-
Notifications
You must be signed in to change notification settings - Fork 40.5k
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
Shut down Reactor Schedulers for WAR deployments #41548
Comments
I think that calling Can you try this and let us know if this works out? |
That works, thanks. :) Is this bleeding out from the framework internals? I don't see the demo app explicitly initiating anything via Scheduler and didn't realize a shutdown hook was needed. |
So, to summarize:
As far as I understand, we can safely shut down schedulers in such an environment, as instances are tied to the application classloader and not the entire JVM. So there is no risk of shutting down a scheduler that's currently used by another application currently running on the same Servlet container. As a first step here, I'd like to consider the lifecycle angle of this case and ask @chemicL for some thoughts on the case here:
I have just discussed this with @rstoyanchev and we will consider enhancements to only call |
There is the broader lifecycle angle question to be considered. Even a Spring for GraphQL application that's using Spring MVC as a transport could need a Specifically for the sample here, however, a |
We had a brief exchange with @bclozel about the points raised above. I'm happy to help in Framework's/Boot's lifecycle management of the Scheduler instances. One idea that comes to mind is to not replace the static ones, but explicitly use specific Scheduler implementations in Spring which are in control of the framework. They would not create risks of colliding with 3rd party library expectations or user-defined long running periodic tasks or shutdown hooks. The drawback for Spring would be the necessity to always feed operators with these instances. Also it could be perceived as a breaking change for users. We can discuss this further and consider various options. |
I have discussed this with the Spring Boot team, and we think this case is quite similar to #21221. So we would like to consider expanding the As a first step, I will use the sample you provided to test this approach and then apply the appropriate change. In the meantime, please consider adding a Transferring this issue to Spring Boot. |
Hi,
I'm attaching a a modified version of the graphql-server project from the Spring Getting Started Guide. The only real modifications are the addition of Spring Data & H2 as dependencies, plus some standard configuration. When deploying the application as a WAR file to 10x Version Tomcat it would appear the memory is not being released following shutdown of the application.
I'm only able to reproduce the problem when using spring data and spring graphql in tandem. I cannot reproduce the problem when using one without the other.
gs-graphql-server.zip
The text was updated successfully, but these errors were encountered: