AbstractApplicationEventMulticaster can leak classes [SPR-11606]

[spring-projects-issues]

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:

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

Backported to: 3.2.9

[spring-projects-issues]

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]

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