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

Doc: Avoid deadlock in @PostConstruct through SmartInitializingSingleton or ContextRefreshedEvent #25074

Closed
izeye opened this issue May 14, 2020 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: documentation A documentation task
Milestone

Comments

@izeye
Copy link
Contributor

izeye commented May 14, 2020

Affects: 5.2.6.RELEASE

The following scenario triggers deadlock:

  • Run non-main threads that invoke a method of @Repository bean in @PostConstruct block.
  • The method throws an exception.
  • Wait the non-main threads to be completed in @PostConstruct block.

This is a sample project to demonstrate it: https://github.com/izeye/spring-boot-throwaway-branches/tree/post-construct-deadlock

Just running it will trigger deadlock.

I'm not sure if this is unsupported usage or bug.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label May 14, 2020
izeye added a commit to izeye/spring-boot-throwaway-branches that referenced this issue May 14, 2020
@izeye
Copy link
Contributor Author

izeye commented May 14, 2020

On second thought, my scenario seems to be better suited to use ApplicationStartedEvent, so feel free to close this if it's unsupported or illegal usage.

See https://github.com/izeye/spring-boot-throwaway-branches/tree/post-construct-deadlock-application-listener

@izeye
Copy link
Contributor Author

izeye commented May 14, 2020

Sorry for back and forth, but ApplicationStartedEvent doesn't seem to work for my scenario.

I want a hook before application start-up, but handling it in ApplicationListener.onApplicationEvent() doesn't seem to block application start-up. I also want application to fail to start by throwing an exception, but it doesn't seem to be the case, either.

izeye added a commit to izeye/spring-boot-throwaway-branches that referenced this issue May 14, 2020
This commit also adds sleep to ApplicationListener.onApplicationEvent() to see if it's blocking application start-up.

See spring-projects/spring-framework#25074 (comment)
@rstoyanchev rstoyanchev added the in: core Issues in core modules (aop, beans, core, context, expression) label Nov 12, 2021
@jhoeller
Copy link
Contributor

jhoeller commented Jul 14, 2023

For such a scenario, your bean should either implement SmartInitializingSingleton.afterSingletonsInstantiated() or rely on the context refresh event: ApplicationListener<ContextRefreshedEvent> or @EventListener(ContextRefreshedEvent.class). Those phases are meant for post-initialization work, so you could easily trigger your asynchronous repository tasks from there. And both variants would would cause the application startup to fail, while still coming after all regular singleton initialization and therefore outside of any container lock.

Alternatively, you may implement the (Smart)Lifecycle interface and integrate with the container's overall lifecycle management, including an auto-startup mechanism, a pre-destroy stop step, and potential stop/restart callbacks.

I'll turn this into a documentation ticket for such purposes.

@jhoeller jhoeller self-assigned this Jul 14, 2023
@jhoeller jhoeller added type: documentation A documentation task and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jul 14, 2023
@jhoeller jhoeller changed the title Deadlock in @PostConstruct block Doc: Avoid deadlock in @PostConstruct through SmartInitializingSingleton or ContextRefreshedEvent Jul 14, 2023
@jhoeller jhoeller added this to the 6.0.12 milestone Jul 14, 2023
@jhoeller jhoeller added the for: backport-to-5.3.x Marks an issue as a candidate for backport to 5.3.x label Jul 14, 2023
@github-actions github-actions bot added status: backported An issue that has been backported to maintenance branches and removed for: backport-to-5.3.x Marks an issue as a candidate for backport to 5.3.x labels Jul 14, 2023
@sbrannen sbrannen changed the title Doc: Avoid deadlock in @PostConstruct through SmartInitializingSingleton or ContextRefreshedEvent Doc: Avoid deadlock in @PostConstruct through SmartInitializingSingleton or ContextRefreshedEvent Jul 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: documentation A documentation task
Projects
None yet
Development

No branches or pull requests

4 participants