[
https://issues.apache.org/jira/browse/SLING-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112331#comment-18112331
]
Joerg Hoh commented on SLING-13329:
-----------------------------------
I acknowledge that calculating the queue size can be slow, when the queue
contains many elements. But I doubt that the solution is to cap the number of
queue entries that are counted; then there is no way to get the actual number
of elements in the queue.
As a short-time solution we could a new method {{getQueueCountCapped()}} which
is implemented as suggested, but the current code should exist. On a more
long-term solution we should investigate our options to improve the existing
logic, and speed up {{ResourceQueueUtils.getEntries()}} and the
{{ResourceIterator}}.
> Cap Distribution Queue status count at 1,000 items to keep large-queue UI
> responsive
> ------------------------------------------------------------------------------------
>
> Key: SLING-13329
> URL: https://issues.apache.org/jira/browse/SLING-13329
> Project: Sling
> Issue Type: Improvement
> Reporter: Aamir bhat
> Priority: Major
>
> *BACKGROUND*
> The Granite Distribution Queue console (both the queue list view and the
> per-queue detail panel) displays a "pending items" count for each
> distribution queue. This count is computed by walking the full JCR resource
> tree under the queue's root node and counting leaf entries.
> For queues that accumulate a large backlog (tens of thousands of items or
> more — e.g. during a slow downstream agent, a paused queue, or a large bulk
> publish), this traversal becomes expensive. Because the count is recomputed
> on every load of the console/status page, large queues make the Distribution
> UI slow to load or effectively unresponsive, even though the underlying
> distribution mechanism itself is functioning normally. This is purely a
> UI/status-reporting performance problem, not a distribution-correctness
> problem.
> h3. CURRENT BEHAVIOR
> * getResourceCount() in the distribution queue resource layer performs an
> unbounded traversal of all queue entries and returns the exact count,
> regardless of queue size.
> * The console and detail panel render this exact count as-is (e.g. "42,318
> Items Pending"), with no upper bound on how large that number — or how long
> the underlying traversal — can get.
> h3. PROPOSED CHANGE
> Introduce a fixed cap on how much traversal work is done purely for
> status/console display purposes:
> * Stop counting once the number of traversed entries exceeds 1,000.
> * If the queue has 1,000 or fewer items, the count is exact and behaves
> exactly as it does today.
> * If the queue has more than 1,000 items, report the count as capped —
> displayed as "1,000+" rather than the true (larger) number — so the UI never
> has to fully walk a large queue just to render a status line.
> * Make the capped state visible to the user rather than silently showing a
> misleadingly-round number:
> ** A tooltip on the "1,000+" label explaining that the count is capped for
> performance.
> ** A one-time informational toast on the console page when any visible queue
> is in a capped state, so users understand why counts look approximate.
> h3. IMPLEMENTATION DETAILS
> *Backend — sling-org-apache-sling-distribution-core*
> * ResourceQueueUtils.getResourceCount(Resource root): change from
> `getEntries(root, 0, -1).size()` (unbounded, builds a full list) to a direct
> bounded traversal using the existing ResourceIterator — increment a counter
> per entry and return early with the cap value as soon as the count exceeds
> STATUS_ITEMS_COUNT_CAP (= 1,000), instead of continuing to walk the rest of
> the tree.
> * Add STATUS_ITEMS_COUNT_CAP constant (1,000) alongside the existing
> queue-resource constants.
> * This method is called from both ResourceQueue.getStatus() and
> ActiveResourceQueue.getStatus(), so the fix automatically applies to both
> queue types that back the console.
> h3. ACCEPTANCE CRITERIA
> * A queue with fewer than 1,000 items shows its exact count, unchanged from
> current behavior.
> * A queue with 1,000 or more items shows "1,000+" instead of the exact
> count, with a tooltip explaining the cap.
> * Loading the console/detail pages for a queue with a very large backlog no
> longer requires a full traversal of that queue — response time is bounded
> regardless of actual queue size.
> * When one or more queues on the console page are capped, a single info
> toast is shown once per page load (not repeated on refresh/polling).
> h3. TESTING PLAN
> * Unit test on the backend confirming getResourceCount() returns exactly
> 1,000 for a queue with more than 1,000 entries, and the true count for
> smaller queues.
> * Manual verification in the Distribution UI: seed a queue with 1,000+ items
> and confirm the "1,000+" label, tooltip text, and one-time toast all appear
> as expected; confirm a small queue still shows an exact count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
