Okhttp ignores Dispatcher settings when used with Retrofit RxJavaCallAdapterFactory

Consider the following OkHttp and Retrofit initializations:

public static SomeServiceRestInterface newRestService(String apiUrl) { Retrofit retrofit = new Retrofit.Builder() .baseUrl(apiUrl) .client(createOkHttpClient()) .addCallAdapterFactory(RxJavaCallAdapterFactory.createWithScheduler(Schedulers.io())) .addConverterFactory(createGsonConverter()) .build(); return retrofit.create(SomeServiceRestInterface.class); } private static OkHttpClient createOkHttpClient() { Dispatcher dispatcher = new Dispatcher(); dispatcher.setMaxRequestsPerHost(1); dispatcher.setMaxRequests(1); OkHttpClient.Builder builder = new OkHttpClient.Builder() .dispatcher(dispatcher).build() } 

While testing the rest of the calls, I noticed that Okhttp does not respect the setMaxRequestsPerHost or setMaxRequests settings. Here is a log of 3 requests sent simultaneously:

 23/07 04:14:22.668 [RxIoScheduler-4] DEBUG - --> POST https://XXX/1 http/1.1 23/07 04:14:22.668 [RxIoScheduler-4] DEBUG - Content-Length: 0 23/07 04:14:22.668 [RxIoScheduler-4] DEBUG - --> END POST (0-byte body) 23/07 04:14:22.672 [RxIoScheduler-7] DEBUG - --> POST https://XXX/2 http/1.1 23/07 04:14:22.673 [RxIoScheduler-7] DEBUG - Content-Length: 0 23/07 04:14:22.673 [RxIoScheduler-7] DEBUG - --> END POST (0-byte body) 23/07 04:14:22.676 [RxIoScheduler-6] DEBUG - --> POST https://XXX/3 http/1.1 23/07 04:14:22.677 [RxIoScheduler-6] DEBUG - Content-Length: 0 23/07 04:14:22.677 [RxIoScheduler-6] DEBUG - --> END POST (0-byte body) 

where XXX is the same domain, 1/2/3 are different paths.

I am not sure why, but I thought this was possibly due to the RxJava scheduler installed in addCallAdapterFactory.

This is mistake? or am I missing something?

I am using okhttp 3.4.1 and modifying 2.1.0.

+5
source share
1 answer

To quote Jake Wharton on this subject:

The Observable for Retrofit implementation executes queries synchronously relying on the application scheduler for any constraint. If you need restrictions from the OkHttp manager, you will need to write your own CallAdapter for monitoring that uses Call.enque instead of Call.execute.

We currently do not plan to support this, although it is likely that Upgrading v3, built on the hypothetical OkHttp v4, can do this by default (although this is far).

This is the same behavior you would see if you used Retrofit Call and called .execute (), or even used OkHttp Call with its .execute ().

+4
source

All Articles