BeanCurrentlyInCreationException is thrown when multiple threads simultaneously try to create bean #34186
Comments
spring-projects-issues
added
the
status: waiting-for-triage
jhoeller
added
the
in: core
jhoeller
added
type: regression
|
@marosrojis I've revised this towards on-demand locking for a specific bean when encountering a |
|
@jhoeller I tested my application with 6.2.2-SNAPSHOT. |
|
Good to hear! Thanks for the immediate feedback, @marosrojis. |
We had quite same issue on several Spring (not spring boot) webapps when migrating from 6.1.x to 6.2.1. Should I create a new issue @jhoeller or simply add you more information (because I'm aware that above log is unhelpful like that) on this thread (starting tomorrow 16jan GMT+1)? |
|
We're also having bean dependency issues on startup after upgrading from Spring 6.1.14 to 6.2.2 |
|
As of 6.2.2, this kind of issue can only happen if another thread concurrently initializes common beans while the main thread tries to initialize all singletons in the preInstantiateSingletons phase. In general, such uncontrolled concurrent startup is not expected in web applications. Other threads are supposed to wait before hitting the context until the ContextLoaderListener has finished its initialization step. Before 6.2, this might implicitly have happened due to waiting for the singleton lock but it really should have been guarded by a custom lock even before. You'll need to find out which other threads hit the context there and make them wait until the context has been fully initialized. Or at least, make sure that the affected beans (such as 'userExportManager' in your case) are initialized early enough - namely, before those other threads start creating beans that depend on those common beans. The startup order can be enforced through corresponding |
|
Thanks @jhoeller for the explanation, however it's frustrating that this just starts happening after a Spring upgrade for an app that's been initialising fine for 10+ years. In any case, and not sure why, but I fixed the dependency issues on startup in our app by renaming this autowired field: (UserExportManager is a class annotated with @service) Hope that's useful for other people! |
|
@anabright sorry for the disruption during that upgrade, and thanks for digging into it. Good to hear that you found a way out for your scenario for a start. I assume that Are you aware which other thread concurrently triggers the initialization of singleton beans there on startup? We are still in the process of understanding the scenarios that can run into problems in that area. No need for deeper insight into your setup, just a general hint in terms of which other thread is involved and where it is being started. If there is something specific we can tweak to keep avoiding deadlocks in concurrent initialization scenarios (our original goal in 6.2 here) while still remaining backwards-compatible in terms of locking in uncontrolled concurrent initialization scenarios, we'd be happy to consider that for 6.2.3. |
Affects: 6.2.1
It is similar problem what is described in the issue 33972.
After upgrade to Spring boot 3.4.0 (Spring 6.2.0) we sometimes see a BeanCurrentlyInCreationException in our logs after application startup.
I upgraded to Spring boot 3.4.1 (with fix from the issue 33972 but
BeanCurrentlyInCreationExceptionstill pops up from time to time.My application is Spring gateway using WebFlux.
Unfortunately I cannot reproduce it in the unit or integration tests.
This was working fine in spring 6.1.15 and is broken in 6.2.0 and 6.2.1.
I enable
TRACElog messages from classesorg.springframework.beans.factory.support.DefaultListableBeanFactoryandorg.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.I include whole log from the application.
app.log
The text was updated successfully, but these errors were encountered: