The default configuration for Scriptd is empty, meaning it should do nothing.

However, the CPU usage of the Scriptd threads increases proportionally to the events injection rate (and fluctuates around some average). That means, on a busy system that is processing thousands of events per second, the amount of CPU taken by Scriptd can decrease the overall performance of OpenNMS, preventing other features from working properly.

I think it would be useful that Scriptd analyses the configuration and inhibit itself from listening to events when there is no configuration requiring that. And when there is a need for a listener, make sure it won't overwhelm the rest of the JVM.

On the system on which I observed this the first time, Actiond was also behaving similarly. I've never seen a customer using Actiond before, but certainly, Scriptd is more widely used, which is why I focused this issue on it.

I'm targeting M2020 and the latest H27 because before the refactoring to use Immutable Events, the impact on CPU was not that high, which makes me believe that code change might be related.

I used jvm-tools to analyze a clean system running 27.1.0:

Also when using stress-events via Karaf Shell to generate 2000 events per second, I can see:

I believe that's excessive for something that is not being in use.