RFR: 8277969: HttpClient SelectorManager shuts down when custom Executor rejects a task [v2]

[Jaikiran Pai]

On Wed, 9 Mar 2022 12:09:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 179:
>> 
>>> 177:             } catch (Throwable t) {
>>> 178:                 errorHandler.accept(command, t);
>>> 179:                 ASYNC_POOL.execute(command);
>> 
>> Does this mean that we will now attempt to use an `ASYNC_POOL` even if a had supplied an `Executor`? The `CompletableFuture#defaultExecutor` which is what the `ASYNC_POOL` represents states:
>> 
>> Returns the default Executor used for async methods that do not specify an Executor.
>> 
>> which would now contradict with this code. With the error handler logic in place (one line above), do you think we should just give up on running the `command` instead of passing to the default executor?
>> 
>> Furthermore, if we do decide to use the default executor in cases like this, is that something that all implementations of the `HttpClient` are expected to do (i.e. would it be a specification) or is this more an implementation detail.
>
> 1. Dependent actions added by the caller to the CF returned by the HttpClient are executed in the FJP
> 2. This is an exceptional case - we're doing this only when we're shutting down the HttpClient. I don't think we should document it - this is an implementation detail. But we should probably document that shutting down the executor while operations are still in progress can lead to unpredictable/unspecified behavior.
> 
> Note: If we had VirtualThreads we would probably create a new VirtualThread here, rather than using the FJP.

Thank you for that clarification, especially this part which I wasn't aware of:

> 1. Dependent actions added by the caller to the CF returned by the HttpClient are executed in the FJP

-------------

PR: https://git.openjdk.java.net/jdk/pull/7196