Skip to content

Stop flooding the scheduled executor with no-op tasks for change count updates#486

Open
tjwatson wants to merge 3 commits intoapache:masterfrom
tjwatson:felixLogParams
Open

Stop flooding the scheduled executor with no-op tasks for change count updates#486
tjwatson wants to merge 3 commits intoapache:masterfrom
tjwatson:felixLogParams

Conversation

@tjwatson
Copy link
Member

@tjwatson tjwatson commented Mar 12, 2026

This PR has two commits

  1. Update various debug statements to use message parameters instead of eager String concatenation.
  2. Updates to the task for setting the change count service property.

On startup SCR will blast change count updates for each
component it satisfies and activates etc.

This resulted in a very large number of task being submitted
to the scheduled executor.  Prior to using an executor a Timer
was used.  In both cases the tasks would wait a default of 5
seconds before updating the change count service property.

Every task submitted would be a no-op except the very last one
which had the "final" change count value.  This behavior is
to avoid flooding the system with service modified events.

The issue is that now we are flooding the scheduled executor
with a significant number of task that most all do nothing.
Since moving to an executor we noticed a non-trivial bump in
our CPU usage when the default 5 seconds passes to run all
the queued tasks.

It turns out that on the JVM we are using the Timer is actually
more efficient than the scheduled executor for popping off
all the tasks and running them when the delay timeout is hit.

The overall design here is sub-optimal regardless.  Flooding
a queue with all but one task that do nothing is not efficient.
This change moves to using a simple repeating task that just
updates the change count service property, if needed, every
delay period (defaults to every 5 seconds).
After at least 10 seconds of inactivity this will cancel
the ScheduledFuture for updating the change count service
property.  If later the change count is updated then a
new ScheduledFuture is submitted.
return;
}
try {
Long registeredChangeCount = (Long) currentReg.getReference().getProperty(PROP_CHANGECOUNT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think getReference, just like setProperties, can throw an IllegalStateException. Should that also not be ignored, currently it will end up in the catch block where it is logged as a warning.

public ComponentRegistry(final ScrConfiguration scrConfiguration, final ScrLogger logger, final ScheduledExecutorService componentActor )
{
m_configuration = scrConfiguration;
m_updateChangeCountPropertyTask = new UpdateChangeCountProperty(m_configuration.serviceChangecountTimeout());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should a safe guard be implemented here to deal with a timeout of 0 being configured? With the updated approach using a 'delay' of 0 does not when calculating the maxNumberOfNoChanges nor using it as interval when scheduling a task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants