Managed executor thread has the AppClassLoader on HttpClient dependent task about quarkus

[antoniomacri]

Setting -XX:ActiveProcessorCount=N, instead of running in a docker container with cpu limit, produces the same results.

[geoand]

Thanks for reporting.

I believe this is not a Quarkus issue

[antoniomacri]

Hi @geoand. Could you expand on that?

[geoand]

We don't do anything specific for either the HTTP client or respond specifically to container limits.

I would suggest trying to reproduce something similar (essentially the executor not being taken into account) with plain Java

[antoniomacri]

I may be wrong, but the executor seems OK to me. From this code:

    @PostConstruct
    void createHttpClient() {
        this.httpClient = HttpClient.newBuilder()
                .executor(managedExecutor)
                .version(HttpClient.Version.HTTP_2)
                .build();

        managedExecutor.supplyAsync(() -> "").thenApplyAsync(response -> {
            Log.infof("PostConstruct thread=%s", Thread.currentThread().hashCode());
            Log.infof("PostConstruct classLoaderAfter=%s", Thread.currentThread().getContextClassLoader());
            return Thread.currentThread().getContextClassLoader().getClass().getName();
        }, managedExecutor);
    }


    @GET
    @Produces({MediaType.TEXT_PLAIN})
    public CompletableFuture<String> test() {
        URI uri = URI.create("http://www.columbia.edu/~fdc/sample.html");
        HttpRequest request = HttpRequest.newBuilder().GET().uri(uri).build();

        Log.infof("classLoaderBefore=%s", Thread.currentThread().getContextClassLoader());
        return httpClient.sendAsync(request, HttpResponse.BodyHandlers.ofString()).thenApplyAsync(response -> {
            Log.infof("thread=%s", Thread.currentThread().hashCode());
            Log.infof("classLoaderAfter=%s", Thread.currentThread().getContextClassLoader());
            return Thread.currentThread().getContextClassLoader().getClass().getName();
        }, managedExecutor);
    }

I get this log:

2024-06-23 08:46:15,765 INFO  [ClassloadingResource] (executor-thread-1) PostConstruct thread=10217343
2024-06-23 08:46:15,765 INFO  [ClassloadingResource] (executor-thread-1) PostConstruct classLoaderAfter=io.quarkus.bootstrap.runner.RunnerClassLoader@1
2024-06-23 08:46:15,766 INFO  [ClassloadingResource] (vert.x-eventloop-thread-1) classLoaderBefore=io.quarkus.bootstrap.runner.RunnerClassLoader@1
2024-06-23 08:46:16,093 INFO  [ClassloadingResource] (executor-thread-2) thread=1224931749
2024-06-23 08:46:16,094 INFO  [ClassloadingResource] (executor-thread-2) classLoaderAfter=jdk.internal.loader.ClassLoaders$AppClassLoader@3d71d552

The thread appears to be from the managed executor.

The problem seems related to the classloader not being set/propagated on thread context.

Correct?

[dmlloyd]

This does seem like a real bug to me. Our thread pools should always be propagating the correct class loader, so it's odd that it's being erased somehow.