ApplicationEventMulticaster should efficiently dispatch according to event type and source [SPR-2572]

[spring-projects-issues]

Matt Jensen opened SPR-2572 and commented

I am working on an application which registers a relatively large number of ApplicationListeners and multicasts a large number of events to them via the application context. The standard SimpleApplicationEventMulticaster is not particularly efficient in this scenario, so I have made an attempt at putting together an improved implementation of the ApplicationEventMulticaster interface. I would like to submit my work for possible inclusion in Spring or Spring Modules.

Key points are:

• New ApplicationListener subclass introduced, SelectiveApplicationListener. Implementors can use two new methods, eventClasses() and sourceClasses(), to limit the types of events and/or sources for which it is notified.
• Subclasses of the event and source classes are handled appropriately...if a listener registers for MyEvent and MySubclassEvent extends MyEvent, then the listener will be notified of MyEvent and MySubclassEvent as one would expect. Same applies to the source class.
• Soft cache of event/listener affinity is maintained internally for performance reasons, as all listeners must be scanned when a new event/source class combination is encountered.
• No reflection or "instanceof"-type logic is needed after the first encounter of any event/source class combination.

I would be happy to make any implementation or style changes necessary to fit the conventions of the Spring project. I will attach all current code to this JIRA issue.

---

Affects: 2.0 RC3

Attachments:

• selectiveApplicationEventMulticaster.zip (25.16 kB)
• selectiveApplicationEventMulticaster.zip (24.59 kB)
• selectiveApplicationEventMulticaster.zip (13.46 kB)

[spring-projects-issues]

Matt Jensen commented

The attached implementation will probably freak out if it is presented with an interface in a sourceClasses() result. I will resolve that issue and attach a patch at a later date--surely long before work on 2.1 RC1 takes center stage. :-)

[spring-projects-issues]

Matt Jensen commented

The attached update removes the Commons Collections dependency and supports interfaces in the type set returned by SelectiveApplicationListener.sourceClasses().

[spring-projects-issues]

Matt Jensen commented

I have modified this code again to make it a bit friendlier in terms of memory consumption. I will attach the latest version shortly.

[spring-projects-issues]

Matt Jensen commented

Latest version, splits class affinity map into a separate class and holds separate affinity lists for source and event classes. Trades off a bit of performance for a bit of memory savings.

[spring-projects-issues]

Juergen Hoeller commented

As of Spring 3.0 M2, SimpleApplicationEventMulticaster is significantly more capable than before. Aside from detecting the generic event type that an ApplicationListener<T> has been declared with, we also support early exclusion of events with non-matching sources. All of this is done with caching of event/source-filtered listeners now - similar in intent to the solution that you proposed. Finally, we also support an @Async annotation now - for any kind of bean, but particularly useful for listener methods, indicating that the specific annotated listener may be invoked asynchronously whenever a matching event comes in.

Juergen