-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Spring Framework 6.2.6: deadlock when starting application after migration Spring Boot 3.3.11 to 3.4.5 #34874
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
Comments
This seems to be similar to the previously reported Pekko scenarios where your scheduler gets activated before all the common beans are created. This could be solved through ordering: making sure that the common beans come first in the order of definition, possibly with the scheduled declaring For Quartz specifically, it could also help to specify a |
Hello @jhoeller , I've added config setting I also replaced org.quartz.Scheduler.start() (what we used to employ) by org.quartz.Scheduler.startDelayed(5) - that doesn't change anything either - except, that it now takes +5 seconds. If I disable org.quartz.Scheduler.start()/startDelayed(x) completely, the application starts w/o any issues - but the schedulers are missing, of course. Thanks. |
Just double-checking: Where have you been setting If a delayed start of the scheduler does not change anything, I wonder what your main bootstrap thread does in the meantime - since it should continue initializing the non-lazy singleton beans in the order of definition. Are those affected common beans declared as lazy-init by any chance? Also, if you perform the Quartz Scheduler start manually rather than through Spring's Quartz integration, you should make sure to do so in a |
Hello @jhoeller , I'm sorry, I just added that config option to the application.yml - not as VM parameter. Changing that, it worked :) Thanks a lot. |
Thanks for the feedback, @stefan-schilling. I'll close this issue now. |
Hello,
we're trying to migrate our applications from Spring Boot 3.3.11 (actually: 3.2.12, but everything seems to be working w/ 3.3.x). We've done that successfully for 9 of them, but 1 is showing failure below:
One of the modules define Quartz-based schedulers (total of 14), of which 3 have an issue, which kind of looks like a deadlock when launching the application.
It always gets to the message
Then we get log messages such as
The last message gets repeated after some time, I guess, Quartz notices, that a job wasn't finished.
But the application does not continue to be fully started (e.g. Tomcat won't finish its boot and therefore does not request any ports for it).
Sadly, I cannot debug this, since logging class o.s.b.f.s.DefaultListableBeanFactory doesn't print message "Obtaining singleton bean ..." anywhere. So I don't know where to look.
On the other hand, if I disable the 3 (out of 14) schedulers, the application will boot successfully.
I never get any error message, so there seems to be no timeout involved.
Since we're using Spring Framework 6.2.6, we're not getting
org.springframework.beans.factory.BeanCurrentlyInCreationException
as #34373 reported.I cannot give you a reduced sample application, since our code seems to be ok (all services injected here are used by other services, too - but their presence does not prevent the application from starting). It fails for this specific combination only. And: though it currently quite persistently fails on my machine, my colleague currently cannot reproduce the issue using Intellij - but when he runs the jar file on his Mac, it fails there, too.
Sorry for being so unspecific, but this looks like a time/order related thing.
The text was updated successfully, but these errors were encountered: