Skip to content
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

Deadlock in @PostConstruct block #28938

Closed
uhushcha opened this issue Aug 8, 2022 · 2 comments
Closed

Deadlock in @PostConstruct block #28938

uhushcha opened this issue Aug 8, 2022 · 2 comments
Labels
status: duplicate A duplicate of another issue

Comments

@uhushcha
Copy link

uhushcha commented Aug 8, 2022

Found it in 5.3.22

In PostConstruct i make a call for subscribe to event ( in external system)

I use webclient and tracing ( spring cloud sleuth)
I got deadlock in DefaultSingletonBeanRegistry.getSingleton method. When webclient try to make a call. By default weblient use reactor.netty.http.brave.TracingHttpClientDecorator. After this application try to get and create singleton bean org.springframework.cloud.sleuth.autoconfig.brave.BraveSamplerConfiguration$RefreshScopedSamplerConfiguration and try to get "synchronized (this.singletonObjects)" in DefaultSingletonBeanRegistry.getSingleton

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Aug 8, 2022
@kzander91
Copy link
Contributor

You shouldn't do stuff like this in a @PostConstruct method, bean construction hasn't completely finished at that point and using other beans that might themselves not be fully initialized can cause these problems.
Wait for the context to be ready to use and then do your call. If you're using Spring Boot, you can use an event listener:

@EventListener(ApplicationReadyEvent.class)
public void ready() {
  // webClient call here
}

Or have your bean implement CommandLineRunner, which will have it be invoked automatically once the context is ready to use.

@snicoll
Copy link
Member

snicoll commented Aug 19, 2022

It's indeed not a good idea. You could use SmartInitializationSingleton instead as afterSingletonInstantied provides a better callback for things like.

I am going to close this as a duplicate of #20904

@snicoll snicoll closed this as not planned Won't fix, can't repro, duplicate, stale Aug 19, 2022
@snicoll snicoll added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Aug 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

4 participants