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

BeanDefinition-aware BeanPostProcessors should clear cache in case of bean definition reset [SPR-17126] #21663

Closed
spring-projects-issues opened this issue Aug 6, 2018 · 3 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 6, 2018

Timur Strekalov opened SPR-17126 and commented

org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#findAutowiringMetadata puts metadata into the org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#injectionMetadataCache, but nothing ever cleans it, leading to a memory leak in case bean definitions for beans with different names get added and removed. This is particularly visible when using Spring Integration's dynamic flows.


Affects: 5.0.8

Issue Links:

  • #21664 Memory leak in CommonAnnotationBeanPostProcessor ("is duplicated by")
  • #21457 Optimize AbstractAutowireCapableBeanFactory.populateBean(String, RootBeanDefinition, BeanWrapper) to avoid redundant Java Bean introspection
  • #20796 dependentBeanMap won't be rebuilt after destroySingleton and recreate it

Referenced from: commits e64c6df, 28565e2

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 6, 2018

Juergen Hoeller commented

This is currently by design: We always retain the latest metadata per bean name, so we effectively clear it for a replaced bean... but not for an individually removed bean since we expect a follow-up instance to appear for the same bean name.

So in your scenario, you see lots of bean definitions added and removed with different names, and autowiring metadata kept around for bean names which are not in use at all anymore? That's quite unusual from the core container perspective. We'd have to introduce a BeanPostProcessor callback for individual removal of bean definitions by name here, clearing the injection and lifecycle caches for it in various post-processor implementations. Alternatively, we could also simply clear all such caches on bean definition removal.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 6, 2018

Timur Strekalov commented

Yeah, I suppose the scenario is somewhat unorthodox in a generic Spring application - however, I'm using Spring Integration's dynamic flows that get started and stopped every day, and quite a few of them, so the cache builds up and overflows pretty quickly. By the way, #21664 is pretty much the same issue, just a different BeanPostProcessor.

Thanks for looking into this so quickly.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 6, 2018

Juergen Hoeller commented

I've introduced a resetBeanDefinition(beanName) notification on MergedBeanDefinitionPostProcessor, applying to Autowired as well as Common and PersistenceAnnotationBeanPostProcessor, allowing them to reset their internal caches accordingly. We're triggering this both on replacing and removing a bean definition since it is sensible to immediately clear the caches in both cases, even if it would implicitly happen later on for the replace case anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.