Skip to content

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

Merged
tjwatson merged 5 commits intoapache:masterfrom
tjwatson:felixLogParams
Mar 27, 2026
Merged

Stop flooding the scheduled executor with no-op tasks for change count updates#486
tjwatson merged 5 commits intoapache:masterfrom
tjwatson:felixLogParams

Conversation

@tjwatson
Copy link
Copy Markdown
Member

@tjwatson tjwatson commented Mar 12, 2026

This PR does the following

  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 to be a repeating scheduled task.
  3. Cancels the repeating task if ~10 seconds of inactivity pass.

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.
Also protected against IllegalStateException on getReference
Also fix logging for when timeout is less than 1
@tjwatson tjwatson merged commit e1f3e38 into apache:master Mar 27, 2026
3 checks passed
tjwatson added a commit to tjwatson/open-liberty that referenced this pull request Mar 27, 2026
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