Application does not terminate upon completion of CommandLineRunner anymore #25885
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
@eduardobarrena-tc Thanks for the report, but we'll need more information to be able to determine what's changed in Spring Boot 2.4.2 to cause this change in behavior. Please provide a minimal sample that reproduces the problem so we can take a look. You can add a comment with a link to a project on GitHub, or attach a project to the issue as a zip file. |
scottfrederick
added
the
status: waiting-for-feedback
snicoll
changed the title
|
@eduardobarrena-tc I don't think the caps in your description are very useful. To isolate what's holding a daemon thread in the app (Spring Boot should not), you can trigger a thread dump when the job completes and analyze the thread dump. |
Just emotions man... I will investigate and bring more information, not sure yet what is going on. I have a maven parent structure with several dependencies so it is not easy. I am updating from '2.2.5.RELEASE' |
spring-projects-issues
added
status: feedback-provided
snicoll
added
status: waiting-for-feedback
|
This is a thread dump. The issue happens if I update from '2.2.5.RELEASE' to '2.4.2' |
spring-projects-issues
added
status: feedback-provided
|
It looks like Lettuce has started a non-daemon thread that's still running: It's not clear from what you've shared thus far why that would be the case. If you'd like us to spend some more time investigating, I think we'll need the minimal sample that @scottfrederick requested above. |
wilkinsona
added
status: waiting-for-feedback
|
Hi all, here I am attaching a project example with minimum artifacts in order to reproduce the error. I looks an autoconfiguration issue, in my project to get it work I had to disable several autonfigurations and configure things manually. However some module inherit those maven artifacts and do not end properly. It would be nice to have an annotation like @DisableAutoconfiguration (The oposiite to @EnableAutoConfiguration as a friendly alternative to property spring.autoconfigure.exclude). However, it is not so cool that the presence of some artifacts break things :S https://github.com/eduardobarrena-tc/demo-spring-boot-bug-4.2.2 |
spring-projects-issues
added
status: feedback-provided
|
Thanks for the sample project. It looks like this might be a Lettuce issue. Adding I'm going to dig a bit more to see if I can find out what's changed. |
|
This commit redis/lettuce@dabd8b2 fixed redis/lettuce#1489 and now starts the timer eagerly where as before it was lazy. The timer thread isn't a daemon thread so the app continues to run. @mp911de Is this a Lettuce issue? Should the |
|
Lettuce creates a non-daemon thread for the timer, similar to the default
|
|
We're in a bit of a catch 22. The @eduardobarrena-tc you can change your main method to this to force the context to close: public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args).close();
} |
philwebb
added
the
for: team-attention
|
Thanks for that simple and cool solution @philwebb, but just to notice lot of people on internet are using as a recipe the code I have provided. A suggestion: A thing that could be cool to have in the framework would be to have an Thank you all !! |
|
I wasn't able to find the reason why Generally speaking, that issues is likely to impact all netty-based integrations that create a timer instance (e.g. the Cassandra driver). Would it make sense to provide a Boot-specific In Lettuce we could introduce such methods so config classes don't need to work out driver internals. |
|
@eduardobarrena-tc You can already use Spring Boot without auto-configuration, if you look at @SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {If you don't want auto-configuration you can annotate your main class with: @SpringBootConfiguration
@ComponentScanYou can also exclude the |
philwebb
added
for: team-meeting
|
Flagging for team-meeting to discuss a Boot-specific |
|
I'm not sure that something being a Spring Boot application allows us to assume that Netty timer threads should be non-daemon . If Lettuce, for example, isn't in a position to make that assumption in general then I don't think it being used in a Boot app changes the situation. As long as the JVM exits once the context has been closed (either via an explicit call to |
|
All things considered I think we're best off keeping the same threading setup as Lettuce. Explicitly calling |
philwebb
removed
for: team-meeting
I run some java batch processes using this code structure:
Prior spring 2.4.2 my service/process terminates after doing it's Job, so the code was convenient to run batch jobs. Starting from spring 2.4.2 the service instances do not terminate. So image the result all my instances are running in my AWS Batch account causing cost increases and blocking other jobs.
The text was updated successfully, but these errors were encountered: