StructuredExecutor Incompatible with HttpClient?

[Eric Kolotyluk]

Indeed, commenting out

var client = HttpClient.newBuilder()
        //.executor(structuredExecutor)
        .connectTimeout(Duration.ofSeconds(10))
        .build();

Solves the problem, and both sync and async requests work correctly now...
thanks.

My goal here is to eventually run an experiment with multiple tasks making
HTTP requests, and the first one to succeed with a result, should
shutdown/cancel the rest of the tasks, including cancelling any HTTP Client
Tasks.

My ultimate goal is to see if I can lower the the AWS Lambda metered
duration by making multiple requests for the same information, hoping some
endpoints will have lower latency than others.

Again, using newThreadPerTaskExecutor(virtualThreadFactory) seems to work
fine with HTTP Client, so there is something different about
StructuredExecutor.

Is it a goal or non-goal of Project Loom and/or Structured Concurrency
<https://bugs.openjdk.java.net/browse/JDK-8277129> to interoperate with
HTTP Client?

Cheers, Eric


On Mon, Nov 29, 2021 at 8:01 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 29/11/2021 14:50, Eric Kolotyluk wrote:
>
> @Alan Bateman <Alan.Bateman at oracle.com>
>
> Thanks for trying my example...
>
>    1. Using newThreadPerTaskExecutor() with virtual threads does seem to
>    work fine.
>       - However, it's the StructuredExecutor that I really want to test.
>       2. Did you also run the case with the synchronous HTTP request?
>       - Earlier you implied this should work, but it also failed for me.
>    3. Are you saying that StructuredExecutor will never work with the
>    asynchronous HTTP client?
>       - I am building the HTTP client with the StructuredExecutor, so why
>       is the client using threads outside of the tree?
>
>
> In your example, you specify the executor for async and dependent tasks to
> the HttpClient.Builder. If you drop that one line then I would expect both
> the async and synchronous usages of the API will just work. The synchronous
> form replaces the sendAsync + thenApply(body) + join with send + body.
>
> I don't know how common it is to using a custom executor here but it does
> need to examined. It might be that the per-HttpClient "Selector Manager"
> can submitted to the custom executor rather than creating a daemon Thread.
>
> -Alan
>
>