On Wed, 7 Jan 2026 12:45:00 GMT, EunHyunsu <[email protected]> wrote: >> 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.
Hello @ehs208, looking at these issues, I think this might need a bit more work and I don't have a straightforward/easy suggestion to make right now and I will need to take a deeper look at the code and experiment with a few changes. Would it be OK, if I took over the work on this one? I will add you as a contributor for the help you have provided so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28632#issuecomment-3737034265
