Improve queue tail lookup fast path and reduce append lock contention

[peter-lawrey]

This PR improves the Long.MAX_VALUE tail-position lookup path in SingleChronicleQueueStore / SCQIndexing and reduces CPU burn under contended queue writes by using a bounded balanced pauser for write and append locks.

The main behavioural change is that sequenceForPosition(..., Long.MAX_VALUE, ...) now has a dedicated fast path that attempts to anchor the scan from the current writePosition rather than falling through immediately to the indexed-anchor lookup. This makes tail sequence discovery cheaper in the common case and adds clearer perf logging when the code does fall back to the slower path.

What changed

• Added SCQIndexing.sequenceForMaxPosition(...) for Long.MAX_VALUE position lookups.

• Uses the volatile writePosition and sequence tracker to start from the latest known write position where possible.

• Retries briefly on Sequence.NOT_FOUND_RETRY to handle races with an active writer.

• Yields after the first few retries to avoid starving the writer.

• Falls back to the existing indexed lookup if the tracker cannot provide a usable sequence.

• Adds perf-log descriptions so scan origins are distinguishable:

  • fast path from writePosition
  • fall-through from indexed anchor
  • tail-check from lastSequenceNumber

• Avoids restarting the MAX_VALUE fast path after the retry budget has already been spent in lastSequenceNumber(...).

• Replaces readPositionUnlimited(...) use with explicit readLimit / readLimitToCapacity() and bounded readPosition(...).

• Routes SingleChronicleQueueStore.sequenceForPosition(..., Long.MAX_VALUE, ...) through the new dedicated fast path.

• Changes writeLock() and appendLock() to use Pauser.balancedUpToMillis(...), capped by the new system property:

  • chronicle.queue.writeLockPauserMaxMs
  • default: 5

• Adds timeouts to long-running resource/contention tests.

• Adjusts the rolling issue test to create more deliberate concurrent write contention using LockSupport.parkNanos(...).

• Avoids resetting the security manager on Java 17+, where that API is deprecated/restricted.

Why

Long.MAX_VALUE is used as a logical “tail” position. In that case, starting from the current write position is usually much cheaper than scanning forward from an older indexed anchor. The previous path could fall into a brute-force scan, making tail lookups more expensive and harder to diagnose from logs.

The new logging descriptions make it visible whether the intended writePosition fast path was used or whether the code fell back to an indexed-anchor scan.

The lock pauser change also reduces wasted CPU under contention. When the lock holder is another thread, tight spinning does not make progress; a balanced pauser gives a better busy/yield/park progression while still keeping the maximum park duration bounded.

Notes

The default write/append lock park cap is intentionally small at 5 ms and can be tuned with:

-Dchronicle.queue.writeLockPauserMaxMs=<milliseconds>

This keeps the default behaviour conservative while allowing deployments with different contention profiles to tune the lock wait strategy.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud