Aamir bhat created SLING-13329:
----------------------------------
Summary: 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
*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.
*UI — com.adobe.granite.distribution.content*
* detail.jsp (queue detail panel) and queueentry.jsp (queue list row):
introduce ITEMS_COUNT_CAP = 1000L; when itemsPending >= cap, render the display
value as "1000+" instead of the raw number, and add a title/tooltip attribute
explaining the cap.
* distribution.js: introduce a matching ITEMS_COUNT_CAP = 1000 client-side,
and a showTemporaryQueueCappedMessage() helper that detects capped rows (by
checking for a "+" suffix on the rendered marker) after the queue list loads,
and shows a single foundation-ui info toast per page load if any queue is
capped.
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)
