On Wed, 7 Jan 2026 10:25:09 GMT, Daniel Jeliński <[email protected]> wrote:
>> EunHyunsu has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8371903: Use stateLock to synchronize stream iteration and connection >> closure > > Well with af092399cd5d188fdec4061d33528f6dc0f3a7f0 the `GoAwayWithErrorTest` > deadlocks sometimes, with the following stack traces: > Thread 1: > > > "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)", > > "java.net.http/jdk.internal.net.http.Http2Connection.tryReserveForPoolCheckout(Http2Connection.java:1604)", > > "java.net.http/jdk.internal.net.http.Http2ClientImpl.getConnectionFor(Http2ClientImpl.java:109)", > > "java.net.http/jdk.internal.net.http.ExchangeImpl.attemptHttp2Exchange(ExchangeImpl.java:143)", > > "java.net.http/jdk.internal.net.http.ExchangeImpl.get(ExchangeImpl.java:122)", > > "java.net.http/jdk.internal.net.http.Exchange.establishExchange(Exchange.java:409)", > > "java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:624)", > > "java.net.http/jdk.internal.net.http.Exchange.responseAsync(Exchange.java:447)", > > "java.net.http/jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:483)", > > "java.net.http/jdk.internal.net.http.MultiExchange.lambda$responseAsync0$0(MultiExchange.java:402)", > > Thread 2: > > > "java.base/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)", > > "java.net.http/jdk.internal.net.http.Http2ClientImpl.removeFromPool(Http2ClientImpl.java:225)", > > "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.doTerminate(Http2Connection.java:2135)", > > "java.net.http/jdk.internal.net.http.Http2Connection$Terminator.terminate(Http2Connection.java:2099)", > > "java.net.http/jdk.internal.net.http.Http2Connection.close(Http2Connection.java:899)", > > "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAwayWithError(Http2Connection.java:1481)", > > "java.net.http/jdk.internal.net.http.Http2Connection.handleGoAway(Http2Connection.java:1411)", > > connectionPoolLock and stateLock are acquired in a different order, leading > to the deadlock. @djelinski I addressed the deadlock by moving `close(cause)` outside of stateLock, keeping the stream iteration synchronized while avoiding holding the lock during `close()`. The change works in local testing, but I don’t have a way to validate this under CI conditions. I’m also unsure whether this is the best solution, so I’d appreciate any guidance or alternative suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3718696751
