Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
java.net.SocketTimeoutException from HTTP/2 connection leaves dead okhttp clients in pool
See original GitHub issueTried writing a unit test w/ TestButler on Android w/ no luck, so I’ll write up the steps to reproduce this and include some sample code. This happens if you connect to an HTTP/2 server and your network goes down while the okhttp client is connected to it:
- create an okhttp client
- tell it to read from the HTTP/2 server
- bring the network down
- tell it to read from the HTTP/2 server (it’ll get a SocketTimeoutException)
- bring the network back up
- tell it to read from the HTTP/2 server again (it’ll be stuck w/ SocketTimeoutExceptions)
- if you create new http clients at this point, it’ll work, but the dead http client will eventually come back in the pool and fail.
okhttp client should attempt to reopen the HTTP/2 connection instead of being stuck in this state
Code sample for Android (create a trivial view w/ a button and a textview):
public class MainActivity extends AppCompatActivity {
OkHttpClient okhttpClient = new OkHttpClient();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Button loadButton = (Button) findViewById(R.id.loadButton);
TextView outputView = (TextView) findViewById(R.id.outputView);
loadButton.setOnClickListener(view -> Observable.fromCallable(() -> {
Request request = new Request.Builder()
.url(<INSERT URL TO YOUR HTTP/2 SERVER HERE>)
.build();
Response response = okhttpClient.newCall(request).execute();
return response.body().string();
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(outputView::setText, t -> outputView.setText(t.toString()))
);
}
}
Issue Analytics
- State:
- Created 7 years ago
- Reactions:30
- Comments:139 (21 by maintainers)
Top Results From Across the Web
java.net.SocketTimeoutException from HTTP/2 connection leaves ...
java.net.SocketTimeoutException from HTTP/2 connection leaves dead okhttp clients in pool · 1) create an okhttp client · 2) tell it to read from...
Read more >SocketTimeoutException in Retrofit - android - Stack Overflow
I am trying to POST request to server for fetch data but sometime It's occure SocketTimeoutException !
Read more >java.net.SocketTimeoutException with no lines referencing my ...
java.net.SocketTimeoutException: Read timed out is quite usual error then a peer is not responding for too long due to service outage or poor...
Read more >Diff - platform/external/okhttp - Google Git
Previously OkHttp's connection pool + managed both idle and active connections for HTTP/2, but only idle + connections for HTTP/1.x.
Read more >Socket Connection Timeout Issue In Built Jar File - ADocLib
I built my OkHttpClient using the code below as suggested in java.net.SocketTimeoutException from HTTP/2 connection leaves dead okhttp. Leave a Reply.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think i’m seeing another manifestation of this on 3.5.0, when the server forcibly closes the connection.
We try to establish both a h2 and http1.1 connection. The server responds with 200 to both:
Then at some point we try to read from the http2 connection, which fails in checkNotClosed and throws a StreamResetException
Then, since this is media, we do something that causes a seek to 0 in the media, which needs to reopen the request from the beginning. At this point, we see the same exception as is posted above:
this seems to be very similar to the other cases here, which seem to all be related to an ungraceful shutdown of the connection, and it remaining pooled.
I’ve also confirmed that disabling the ConnectionPool “works around” this issue:
Also still getting this problem on emulator with api 22, and 3.14.4. Also I get a SocketTimeoutException after 2 minutes (what my readTimeout is set to), instead of 10 seconds (what my connectTimeout is set to). The workaround using
.connectionPool(new ConnectionPool(0, 1, TimeUnit.NANOSECONDS))still works. I’d say it’s time to re-open this 😦. Steps to reproduce are same as OP.I can confirm the issue doesn’t exist when using a real device Note 9, API 29.