Right now, all active event listeners have to be loaded and called for every emitted event. I was thinking it might be nice to allow configuration parameters to be added to each EventListener’s dlinit file to define which events it actually cares about. This would allow emitted events to be pre-filtered and dispatched only to relevant listeners. Additionally, the active event slots for a given listener could be managed through the “Configure Events…” dialog in the Monitor, allowing certain slots to be enabled or disabled if necessary.
I started looking into this, and I’m not sure how well it will work with the async job event system we’re considering. For better performance, we are going to load the event plugins once for each batch of async job event triggers, rather than loading them for each event trigger. I’m assuming the goal for this request is to improve event performance, but if the async system is offloading them from the Monitor, is it even necessary any more?
If you still want to enable/disable specific events, you can still add config entries to the dlinit file, and have each event check them to see if they should do anything.
My original thought with keeping the event filtering outside of the listener class was to prevent listeners from being loaded at all unless necessary. Basically, I was thinking that it would allow Deadline to check and see if a given event type even had any listeners that cared about it, and if not, to not even bother loading any event plugins or propagating that event further. To be really effective, it would probably require caching of the listener filters in the database, with some command/control somewhere to re-read the dlinit files and re-generate the filter cache.
In general, the gains would probably be fairly minimal unless you had a very high-traffic farm with lots of quick jobs coming and going. For now, it may be something to just keep in mind for the future if the complexity of the event system increases substantially.