serhiy-bzhezytskyy opened a new pull request, #4639: URL: https://github.com/apache/solr/pull/4639
Picking up the POC Jan left on SOLR-17707. `HttpJdkSolrClient`'s async paths (`requestAsync`, `requestInputStreamAsync`) never cleaned up the content-writing task. When a connection fails while the request body is still being written, that thread stays blocked forever in `PipedInputStream.awaitSpace()`. Because the writer runs on the client's own executor, enough of these exhaust the pool and the client stops working — the thread dump in the issue shows exactly this. The synchronous `requestWithBaseUrl` already cancels the writer in its `finally`; the async paths did not. Both async paths now release the writer via `whenComplete`. One thing worth calling out for review: cancelling the `Future` alone does **not** fix it. In a repro I found `cancel(true)` returns `true` but the interrupt does not reliably reach the thread blocked in the pipe (it stays `TIMED_WAITING`, `interrupted=false`). Closing the pipe's sink is what deterministically unblocks the writer (`IOException: Pipe closed`). The fix does both — close to release a stuck writer, cancel to stop one that hasn't started. Test: `testStuckContentWritingThreadIsReleasedOnFailure` sends a body larger than the pipe/socket buffers to a server that accepts but never reads, then drops the connection, and asserts no writer thread is left blocked in `awaitSpace()`. It fails without the fix and passes with it. This is the reliable reproduction that was hard to pin down earlier — the key was a body big enough to actually block the writer before the failure. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
