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

AbstractApplicationEventMulticaster can leak classes [SPR-11606] #16229

Closed
spring-projects-issues opened this issue Mar 26, 2014 · 2 comments
Closed
Assignees
Labels
in: core status: backported type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 26, 2014

Eric Bottard opened SPR-11606 and commented

This was discovered as part of the PR mentioned above, in the context of XD.

Basically, we create app contexts which have their own classloaders and can come and go. Those contexts (modules in XD terms) have a parent context that lives longer.
If event listeners are installed in the child context, listening for an event type that is loaded by the custom classloader, the parent context will still retain the types and hence the CL long after the child context has been torn down, preventing proper GC.

This gist https://gist.github.com/ericbottard/ad6da5559257fbcb0325 shows the problem (albeit not using a dedicated classloader). Run it using like yourkit and see retention of the custom event type


Affects: 3.2.8, 4.0.2

Reference URL: spring-attic/spring-xd#669

Issue Links:

  • #16145 Memory leak when using annotation based auto-wiring in child context
  • #16618 Changes to AbstractApplicationEventMulticaster in 3.2.9 break HttpSessionEventPublisher in Google AppEngine Runtime

Backported to: 3.2.9

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 26, 2014

Stéphane Nicoll commented

When an even is published in the child context, it is also propagated to the parent. The basic publish mechanism first retrieves the listeners that are eligible for that event and cache them if this has not been the case.

When your sample event is published, the cache of the parent is filled wit a reference to this child event. The problem, as you already mentioned is that ListenerCacheKey holds a reference to a Class and prevents a proper collection of the child context.

One way of fixing this issue would be to clear this cache when a child context is closed as some child-specific information may have been stored in that cache. I have tried that locally and it works as expected but I still need to figure out if that's the proper way to do it and where.

Creating your own ApplicationEventMulticaster won't buy you much: at best you could prevent a caching operation if the context in the event is not "your" context but that can prove to be very inefficient.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 26, 2014

Juergen Hoeller commented

Fixed with an approach similar to #16145, checking cache safety of the event type and source type before adding them to the cache. To be available in the next 4.0.3 snapshot.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: bug
Projects
None yet
Development

No branches or pull requests

2 participants