Joe Witt created NIFI-16370:
-------------------------------
Summary: Use non-fair locking in SwappablePriorityQueue
Key: NIFI-16370
URL: https://issues.apache.org/jira/browse/NIFI-16370
Project: Apache NiFi
Issue Type: Improvement
Reporter: Joe Witt
Assignee: Joe Witt
h3. Background
NIFI-15862 introduced virtual-thread scheduling for TIMER/CRON components.
While validating that change (PR #11164), a CPU-bound GenerateFlowFile →
UpdateAttribute loop showed that two independent pairs scaled additively, but a
third pair did not. JFR recordings on Java 25 showed no virtual-thread pinning
and no disk wait. The hotspot was fair lock acquisition on
SwappablePriorityQueue.put / poll (hasQueuedPredecessors and the associated
park/unpark handoff).
SwappablePriorityQueue constructs:
new ReentrantReadWriteLock(true)
Every FlowFile put and poll takes the write lock. Fairness only orders *threads
waiting for the lock*. FlowFile order is already determined by PriorityQueue
and QueuePrioritizer (penalty, configured prioritizers, content claim, then id).
That fair lock predates virtual threads (present on the original FlowFile queue
and carried into SwappablePriorityQueue in NIFI-5516). Virtual threads made the
cost obvious because many more tasks actually run put/poll at once.
h3. Proposed change
Construct the SwappablePriorityQueue read/write lock as non-fair:
new ReentrantReadWriteLock()
Add a short comment that queue ordering is the comparator, not lock-acquisition
FIFO, and that non-fair locking avoids a thread-handoff convoy on the put/poll
path.
Out of scope:
- StandardFlowFileQueue's outer fair lock (not used by ordinary put/poll)
- Provenance / attribute-map allocation
- QueuePrioritizer comparator changes
h3. Risk
Theoretical waiter starvation / barge-in: a thread that arrives while the lock
is free can skip waiters. The critical section is small (heap operation + size
counters). UI/status readLock snapshots (diagnostics, list queue, duration) can
wait longer under a write storm; that is the same class of issue as any
non-fair RW lock. Queue ordering, swap-in/swap-out order, and size accounting
are unchanged.
h3. Test plan
- TestSwappablePriorityQueue
- TestStandardFlowFileQueue
- Existing load-balanced queue tests
- Optional: JFR on a CPU-bound Generate → UpdateAttribute loop under
AUTO/virtual threads, confirming the fair-lock path is gone from the profile
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
