Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistency in CtOkHttp4Client ExecutorService usage #569

Open
pintomau opened this issue Feb 5, 2024 · 1 comment
Open

Consistency in CtOkHttp4Client ExecutorService usage #569

pintomau opened this issue Feb 5, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@pintomau
Copy link
Contributor

pintomau commented Feb 5, 2024

Hey.

We're evaluating the usage of Virtual Threads with Executors.newVirtualThreadPerTaskExecutor();.

I've noticed that there's an inconsistency in the usage of ExecutorService executor in CtOkHttp4Client:

    public CtOkHttp4Client(final ExecutorService executor) {
        super(executor);
        okHttpClient = clientBuilder.get().dispatcher(createDispatcher(executor, MAX_REQUESTS, MAX_REQUESTS)).build();
    }

    public CtOkHttp4Client(final ExecutorService executor, final BuilderOptions options) {
        super(executor);
        okHttpClient = options.plus(clientBuilder.get().dispatcher(createDispatcher(MAX_REQUESTS, MAX_REQUESTS)))
                .build();
    }

    public CtOkHttp4Client(final ExecutorService executor, final int maxRequests, final int maxRequestsPerHost) {
        super(executor);
        okHttpClient = clientBuilder.get()
                .dispatcher(createDispatcher(executor, maxRequests, maxRequestsPerHost))
                .build();
    }

    public CtOkHttp4Client(final ExecutorService executor, final int maxRequests, final int maxRequestsPerHost,
            final BuilderOptions options) {
        super(executor);
        okHttpClient = options
                .plus(clientBuilder.get().dispatcher(createDispatcher(executor, maxRequests, maxRequestsPerHost)))
                .build();
    }

The second constructor doesn't reuse the passed executorService when creating the dispatcher, while all others that get the same argument do.

It just so happens that this one would be the ideal one for us 🤠.

Is there a reason for this, or is it an oversight?

Besides this, any thoughts or recommendations on using the Virtual Threads executor with the SDK?
Maybe you've already done experimenting on your end? Is the SDK prone to Thread Pinning?

Thanks.

@pintomau pintomau added the enhancement New feature or request label Feb 5, 2024
@jenschude
Copy link
Contributor

We didn't experiment yet with virtual threads.

When I remember it right the executor wasn't forwarded to the OkHttp dispatcher for backwards compatibility reasons as it potentially would have changed the behavior.

In case you want to forward the executor to OkHttp use one of the methods with the maxRequest arguments or rebuild the functionality

ExecutorService executor = ForkJoinPool.commonPool();
final okhttp3.Dispatcher dispatcher = new okhttp3.Dispatcher(executor);
dispatcher.setMaxRequests(CtOkHttp4Client.MAX_REQUESTS);
dispatcher.setMaxRequestsPerHost(CtOkHttp4Client.MAX_REQUESTS);


new CtOkHttp4Client(executor, builder -> builder.dispatcher(dispatcher));

Besides you should load test any changes to the default executor as OkHttp by default instantiates an unbound ThreadPool executor with a SynchronousQueue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants