[PR] Fix deadlock in adapter access tests across named-lock modules [maven-resolver]

["elharo (via GitHub)" <gi...@apache.org>]

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

   Complements #2032 by fixing the same deadlock-prone handshake in NamedLockFactoryAdapterTestSupport (used by IpcAdapterIT, IpcAdapterNoForkIT, the hazelcast/redisson adapter ITs, and the LocalReadWriteLock/FileLock/LocalSemaphore adapter tests).
   
   ## Problem
   
   When both competing threads fail to acquire the lock within the adapter lock wait time (ADAPTER_TIME, default 100 ms, with 1 retry), both Access threads count down the loser latch and then block forever on winner.await(), because the winners latch is never counted down. The tests hang until the JUnit @Timeout fires. Under load (e.g. the in-process IPC server thread starved for more than 100 ms) neither acquisition completes in time, so this deadlocks exactly like the factory-level tests in #2032.
   
   ## Fix
   
   Applied to all four copies of NamedLockFactoryAdapterTestSupport (maven-resolver-named-locks-ipc, -hazelcast, -redisson and maven-resolver-impl):
   
   - Raise ADAPTER_TIME from 100 ms (500 ms in maven-resolver-impl) to 1000 ms so at least one thread reliably wins even on a loaded machine. Mutual exclusion is still verified: the loser is queued behind the winner on the server and cannot be granted while the winner holds, so its failure is still caused by the winner holding the lock.
   - Bound the winner/loser handshake awaits and the test-side joins and latch awaits, and assert the expected outcome, so a pathological both-lose case fails fast with a clear message instead of hanging for the full @Timeout.
   - Bump the @Timeout(5) safety nets to @Timeout(15) in the hazelcast, redisson and impl copies to leave headroom for the longer legitimate loser path (2 attempts x ADAPTER_TIME + retry wait ~ 2.2 s).
   - maven-resolver-impl: also bound the waits in multipleAcquiresWithALoser, releasedExclusiveAllowAccess and fullyConsumeLockTime; fullyConsumeLockTime's duration assertion is derived from ADAPTER_TIME so it remains valid.
   
   ## Verification
   
   - IpcAdapterIT and IpcAdapterNoForkIT: 5 consecutive runs, all passing (9 tests each).
   - maven-resolver-impl: LocalReadWriteLockAdapterTest, FileLockAdapterTest, LocalSemaphoreAdapterTest all pass (13 tests each).
   - maven-resolver-named-locks-hazelcast: HazelcastCPSemaphoreAdapterIT and HazelcastClientCPSemaphoreAdapterIT pass (9 tests each).
   - maven-resolver-named-locks-redisson: compiles; the ITs could not be run locally (they require Docker/testcontainers), but the change is identical in structure to the other three modules.


-- 
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: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fix deadlock in adapter access tests across named-lock modules [maven-resolver]

["elharo (via GitHub)" <gi...@apache.org>]

elharo merged PR #2033:
URL: https://github.com/apache/maven-resolver/pull/2033


-- 
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: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fix deadlock in adapter access tests across named-lock modules [maven-resolver]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] commented on PR #2033:
URL: https://github.com/apache/maven-resolver/pull/2033#issuecomment-5191559325

   @elharo Please assign appropriate label to PR according to the type of change.


-- 
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: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org