[
https://issues.apache.org/jira/browse/NIFI-16370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18117188#comment-18117188
]
ASF subversion and git services commented on NIFI-16370:
--------------------------------------------------------
Commit 6d00883742fa18847a14754cee8994ec487fd534 in nifi's branch
refs/heads/main from Joe Witt
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=6d00883742f ]
NIFI-16370 Use non-fair locking in SwappablePriorityQueue (#11698)
Co-authored-by: Cursor <[email protected]>
> 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
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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)
