Okhttp: Network calls hang after coming back online after being offline

[arstk8]

I have an interesting issue I'm seeing with okhttp, but so far I can only reproduce it on Android emulators (default Android emulator and Genymotion)

If I make a bunch of requests to the same server (enough to saturate the connection pool) and then go offline (airplane mode) and then come back online, any subsequent requests I make to that server hang until one of the connections in the connection pool is removed after 5 minutes of inactivity.

I'm not sure if the emulator thing is a timing issue (emulators execute faster in my experience) or if it's a quirk with the networking configuration vs a real device. The fact that it happens on more than one type of emulator seems significant to me.

I have a sample app which reproduces it here: https://github.com/arstk8/TestEsriNetworkCall/

I know you're preferred way to reproduce is via MockWebserver test case, but I can't figure out a way to reproduce it that way.

[swankjesse]

Thanks for putting together the sample app. If you have any insight into how OkHttp could reliably detect this situation, that’d be handy.

[arstk8]

I don't, unfortunately. The only thing I can think of is some kind of reachability test, but that seems expensive.

[kenumir]

Basing on this example i make some test and:

• there's no need make 40 requests, one is enough
• when request is http/1.1 SocketTimeoutException occurs only on first request (next is ok)
• when request is http/2 SocketTimeoutException occurs on every next request
• when canceling request (http/2) and try make next request everything is getting work

This is my observation, I hope this helps

[ekstro]

Setting "keepAliveDuration" also has an impact on this.

[yschimke]

Had a quick look at this with OkHttp 3.9.0

A few comments:

1) Still happening with 3.9.0
2) The EventListener API makes it a lot easier to understand what okhttp is attempting e.g. when it reuses connections from before airplane mode etc.
3) I can't get http/2 to work to that server - I don't think the server supports ALPN
4) Can reproduce with other Http/2 servers, the connection is reestablished after a couple of requests [edit]

One option might be to support platform reachability services, specifically on Android, and test connections after reachability events before handing them out.

[yschimke]

Tagging as enhancement - I think since this is so easily reproducible even on Android 8 with OkHttp 3.9.0, that detecting this cleanly and making it work will be relatively high impact. n.b. I couldn't get into the permanent http/2 failure state that @kenumir saw, so maybe that is fixed.

[tucomel]

not fixed to me, Im using okhttp3.10 with emulator on android api 27 and just after go back online (turn airplane mode off) at first request the the timeout error come out, but after first request everything works

[minobilis]

I had the same issue on emulator and some samsung devices.
Forcing okhttp client to use HTTP/1.1 helped me to avoid such exceptions.

new OkHttpClient.Builder()
.protocols(Arrays.asList(Protocol.HTTP_1_1))
.build();

It might be due to how HTTP/2 connections established and maintained at OS level on these devices.

[heltonandreazza]

Hey guys,

I thought this was supposed to be fixed here https://github.com/square/okhttp/issues/3261, but I ran @arstk8's sample (https://github.com/arstk8/TestEsriNetworkCall/) with okhttp 3.12.3 and sdk 26, the issue seems to persist.

@minobilis I've also tried your workaround by changing on MainActivity.java:34 new OkHttpClient.Builder().build() to new OkHttpClient.Builder().protocols(Arrays.asList(Protocol.HTTP_1_1)).build() it doesn't fix the problem either.

Apparently the issue presents itself only on Android emulators.

Is there any fix on sight that could be done?
Is there any difference between making HTTP requests on emulators and physical devices?

Thanks in advance!!

[yschimke]

Probably worth retesting after https://github.com/square/okhttp/pull/5920 which is in 4.5, I'm hopeful that fixes a ton of connectivity issues with dodgy Android networking.