-
Notifications
You must be signed in to change notification settings - Fork 40.9k
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
Add 'keep-alive' property to SpringApplication and document that it is useful when using virtual threads #37736
Comments
I'm not sure we'd consider it intentional, but it certainly makes sense given your description about non-daemon threads. We'll need to discuss it as a team to see what our options are. |
We discussed this today. Our feeling was that there's nothing that we can do by default as it's very hard for us to know that the JVM should be kept alive through the existence of a non-daemon thread. If we get it wrong and someone isn't calling |
Thanks a lot for giving it a thought. I'm primarily interested in it being documented because I wasn't sure whether I missed something. I doubt I'm going to be the only one. Having an official mechanism to keep a Spring Boot application alive would be nice, especially because one of the popular workarounds ( |
There's now the property |
With platform threads, a method annotated with
@Scheduled
keeps an empty Spring Boot application running. When virtual threads are enabled, this is no longer the case and the application stops once it has initialized.Example application (generated by Spring Initializr, Spring Boot 3.2.0-M3, no dependencies, Java 21):
With virtual threads enabled, there's only one line of "Running":
With virtual threads disabled, "Running" is printed until the application is stopped with CTRL+C:
On the one hand, it makes sense because Spring Boot stops if there is not at least one non-daemon thread. On the other hand, it is no small change in behaviour. Is it intentional? If so, I could not find any mention in the reference or the release notes. The relevant entry is probably this one from the 3.2.0-M1 release notes about task execution.
The text was updated successfully, but these errors were encountered: