On Wed, 9 Mar 2022 12:09:48 GMT, Daniel Fuchs <dfu...@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
