<div dir="ltr">When overriding the HttpClient executor with a custom ThreadPoolExecutor that uses the default RejectedExecutionHandler.AbortPolicy, the Java HTTP client (java.net.http.HttpClient) becomes permanently unusable if the delegate executor rejects a task.<br><br>This creates a situation where transient thread pool saturation results in a non-recoverable client failure.<br><br>Reproduction of the issue:<br>1. The task rejection triggers a call to the error handler (onSubmitFailure)<br>2. This calls selmgr.abort(failure) with the rejection exception<br>3. SelectorManager.abort() sets this.closed = true permanently<br>4. All subsequent HTTP operations fail with "IOException: selector manager closed"<br><br>The client does not recover from this state.<br><br>I was able to avoid this by using the DiscardPolicy instead of the AbortPolicy. However, this behavior was quite a surprise to debug. Is this behavior intentional, or does it make sense for the HttpClient to treat task rejection as a recoverable error?<br></div>