Cache continued tasks during queue maintenance#565
Open
bennettzhu1 wants to merge 1 commit into
Open
Conversation
Queue maintenance calls QueueTaskDispatcher.canTake for each buildable item and idle executor. ContinuedTask.Scheduler previously scanned every buildable item on each call to find continued tasks, making queue maintenance quadratic in the number of buildables. Maintain a queue-id keyed cache of buildable continued tasks via QueueListener events. The first scheduler call initializes the cache from the current buildable queue, and later queue transitions add or remove entries. Cache entries keep only a weak task reference plus display name and assigned label so stale entries can be dropped during the next scheduler pass. Add coverage for a cached task that stops being continued. Fixes jenkinsci#560
Member
|
Cc @jenkinsci/durable-task-plugin-developers ———- FYI conflicts |
There was a problem hiding this comment.
Pull request overview
This PR introduces a cache of buildable ContinuedTask items to avoid repeated full-queue scans during Queue.maintain, reducing the complexity of ContinuedTask.Scheduler.canTake.
Changes:
- Add a
ConcurrentHashMap-backed cache of buildable continued tasks, initialized on first use and maintained via aQueueListener. - Update
Scheduler.canTaketo consult the cache instead of rescanning all buildables. - Add a regression test ensuring cached tasks are dropped once they are no longer “continued”.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/main/java/org/jenkinsci/plugins/durabletask/executors/ContinuedTask.java | Adds/uses a buildable-continued-task cache maintained via QueueListener to speed up canTake. |
| src/test/java/org/jenkinsci/plugins/durabletask/executors/ContinuedTaskTest.java | Adds test coverage verifying the cache evicts tasks that stop being continued. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+94
to
+114
| private static synchronized void initialize() { | ||
| if (INITIALIZED.compareAndSet(false, true)) { | ||
| for (Queue.BuildableItem item : Queue.getInstance().getBuildableItems()) { | ||
| addIfContinued(item); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| private static Iterable<ContinuedItem> values() { | ||
| return ITEMS.values(); | ||
| } | ||
|
|
||
| private static synchronized void addIfContinued(Queue.BuildableItem item) { | ||
| if (isContinued(item.task)) { | ||
| ITEMS.put(item.getId(), new ContinuedItem(item)); | ||
| } | ||
| } | ||
|
|
||
| private static synchronized void remove(long id) { | ||
| ITEMS.remove(id); | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #560
We have seen jenkins queue maintenance spend a lot of time in
ContinuedTask.Scheduer.canTake. Queue.maintain already iterates through each buildable and idle executor, and then for each buildable, scans the full buildable queue again to see if any are ContinuedTasks.To avoid the full buildable loop again, this PR creates a cache of buildable
ContinuedTaskitems. On first pass, populates the map ofContinuedTasks, else it watches theQueueListenerto update the cache.This brings the execution time from
(buildable)^2 * idle executorstobuildables * idle executors * unique continued tasks. I briefly thought of caching by node to continued task, but it makes updating the cache very messy.Testing done
We tested it in our staging environment, and we are currently running this patch at my company.
Submitter checklist