How to fix "End of stream on null" network issue?

Question

Some users of my Android application are frequently running into a network error with the following error message: "Unexpected end of stream on null".

I didn't find any clear way to solve it by looking at other similar question. I haven't been able to reproduce the network error on my end.

1) I have unsuccessfully appended Connection=close to the requests headers as this answer suggests

2) I have unsucessflly added .retryOnConnectionFailure(true) as this answer suggests

3) I have unsuccessfully searched for a server side issue as this answer suggests but the requests with network issues are not appearing in the nginx access.log file

Here is how I init Retrofit

OkHttpClient okHttpClient = new OkHttpClient().newBuilder()
                .connectTimeout(40, TimeUnit.SECONDS)
                .readTimeout(30, TimeUnit.SECONDS)
                .writeTimeout(30, TimeUnit.SECONDS)
                .retryOnConnectionFailure(true)
                .build();

Retrofit.Builder retrofitBuilder = new Retrofit.Builder()
                .baseUrl(BuildConfig.BASE_URL)
                .addConverterFactory(GsonConverterFactory.create())
                .client(okHttpClient);

this.retrofit = retrofitBuilder.build();

Here is my endpoint definition (in IUserService.java)

@POST("/v2/android/login/phone")
@Headers("Content-Type: application/json;charset=UTF-8;Connection=close")
Call<APIResult<Session>> phoneLogin(@Body APIRequest request);

And here is how the endpoint is queried

userService = retrofit.create(IUserService.class);
Call<APIResult<Session>> call = userService.phoneLogin(request);
call.enqueue(new GenericCallback<>(context, callback));

Our configuration:

Android (Java)

Retrofit 2.3.0: 'com.squareup.retrofit2:retrofit:2.3.0'

Okhttp 3.12.1: 'com.squareup.okhttp3:okhttp:3.12.1'

Server running on AWS Elastic Beanstalk, platform: Puma with Ruby 2.6 running on 64bit Amazon Linux/2.9.0

Can anyone explain better where the problem is coming from? Any idea how to reproduce this issue locally? Any way to solve this issue?

Monroy

Could you provide a minimal working sample of your code ? – Hollander

This appears to be this issue, a know problem in OkHttp. I highly suggest Volley, a Google based network library, I have been using a lot, without any know issues (with most clients at Android-K, and a rare few L, M, N ones)... if the OkHttp is a must, then please, try to add a stacktrace in the question. – Boutis

do you know which scenario is causing this issue – Terrorism

could you post the Http request&response log (both success and failure cases) with the header as well? – Whoremaster

@Boutis We have to use Okhttp indeed. I can't provide a stacktrace for the moment, I'll come back with one as soon as I can – Monroy

@ManojPerumarath The main scenario that causes this error is an user trying to login but can't do it because he's stuck with this network issue (the login endpoint is obviously the first endpoint that is called) – Monroy

@Whoremaster I can't give you the request and response logs because we can't reproduce this issue, it only happens in production – Monroy

@Boutis here is the full stacktrace an user had today: textuploader.com/1r4n2 – Monroy

Answer 1

From the stack trace, in the comments, its possible to see that the problems lies in:

Caused by java.io.EOFException: \n not found: limit=0 content=…

So, this is the original issue. It is likely that a GZIP reduction of the content is not being performed as intended, or at least, the receiver is not expecting it, and not decoding. MDN source. Try to do as following:

.addHeader("Accept-Encoding", "identity")

If this does not work, then its likely a Server error, as this other stackoverflow answer states. Note that you should test the page URL on another tool (such as CURL or something, to rule server issues out)

Boutis

We'll make a release with the additional header soon. I'll let you know if it solved the issue, thanks – Monroy

If possible, add any additional information you might have. It looks like a Server issue, most likely the Client cant understand the reply, due to loss or streaming nature. What headers are set and received? What is the actual result, when tested with CURL or any other tool? What are the characteristics of the devices that are failing, etc. – Boutis

Answer 2

looks more like a server issue, you could try configuring your Server with a keep_alive timeout of 60 seconds (default) as this link suggests.

Distinguishing

We're currently testing it. I will update you if it worked, thanks – Monroy