-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
DefaultListableBeanFactory.getBean(Class) may throw NoSuchBeanDefinitionException when removeBeanDefinition is being called simultaneously to remove an unrelated bean #22263
Comments
For real-world context, in our actual application (not the sample I provided here) the number of beans being added/removed is rather small compared to the total number in the application. They are being added/removed in a task scheduler thread, as here. The other threads in the actual application are HTTP request-handling threads that are using ApplicationContext.getBean for service location. There, we are seeing the NoSuchBeanDefinitionException exception occur sporadically when the HTTP request occurs during remove in the background. As in the sample, the bean(s) being located are not those that are being added/removed. |
Is there anything new about this one? |
…s traversal Closes spring-projectsgh-22263 (cherry picked from commit 30bc5e0)
See spring-projectsgh-22263 (cherry picked from commit f1345aa)
We're seeing sporadic NoSuchBeanDefinitionException exceptions out of ApplicationContext's getBean(Class) when in another thread DefaultListableBeanFactory.removeBeanDefinition(String) is being called, for unrelated/different beans. It appears to be a synchronization issue in DefaultListableBeanFactory's implementation (across use of fields beanDefinitionMap and beanDefinitionNames.) I have included a Spring Boot application that reproduces the issue. Having more beans seems to exacerbate the issue, I presume because it increases time to copy beanDefinitionNames in removeBeanDefinition.
We're seeing this with spring-beans-5.1.4 and 5.1.3, unknown about older versions than that.
Here's an unrealistic application that reproduces the condition, which we ran with spring-boot-starter-parent 2.1.2.RELEASE (spring-beans-5.1.4):
The text was updated successfully, but these errors were encountered: