gnodet opened a new pull request, #2098:
URL: https://github.com/apache/maven-resolver/pull/2098

   ## Summary
   
   - Increase per-operation lock timeout from 5s → 30s in 
`NamedLocksTrackingFileManagerTest`
   - Add proper `FileLockNamedLockFactory.shutdown()` in `@AfterEach` to close 
idle channels and lock files
   
   ## Root cause analysis
   
   The test runs 4 threads × 1000 iterations of concurrent `read(shared)` + 
`update(exclusive)` against the same file, exercising the full 
`FileLockNamedLock` contention path. Each exclusive lock attempt retries with a 
100ms sleep between attempts.
   
   The 5-second timeout was **already bumped from 1s → 5s** in 
[194128ae](https://github.com/apache/maven-resolver/commit/194128ae) ("Seems 
timeout of 1s is not enough?"). Recent performance optimizations (#1937) 
changed the lock acquisition timing characteristics:
   
   1. The **lock-free fast path** in 
`NamedLockFactorySupport.getLockAndRefTrack()` makes `getLock()` much faster, 
allowing threads to re-acquire locks more rapidly and increasing file lock 
contention
   2. The **idle channel pool** in `FileLockNamedLockFactory` (from the FD leak 
fix) adds a small amount of work inside `locks.compute()`, marginally extending 
the time the ConcurrentHashMap bucket lock is held
   
   Neither change introduces a concurrency bug — the channel management is 
correctly serialized by `locks.compute()` bucket locks, and the `tryIncRef` CAS 
sentinel correctly prevents revival of destroyed holders. However, on loaded CI 
machines, the changed timing profile can push borderline operations past the 5s 
threshold.
   
   The factory was also never shut down after tests, leaking idle `FileChannel` 
instances.
   
   ## Test plan
   
   - [x] `NamedLocksTrackingFileManagerTest` passes all 18 parameterized test 
cases (DEFAULT, JIMFS_UNIX, JIMFS_WINDOWS × 6 test methods)
   - [ ] CI passes on this branch
   
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to