Search code examples
restnetwork-programmingjersey-2.0jersey-clientubuntu-16.04

"Error: Writing to server" - Occuring only on ubuntu


I am using a jar file implementing custom functionality which uses jersey as REST client (version 2.22.1). While everything seems to work fine for a few calls, for a specific HTTP call I get a "Error: Writing to server", but only when running in ubuntu.

The error occurs when running a unit test on my two ubuntu development PCs. My development PCs are both Ubuntu 16.04 with Oracle JDK:

~$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

$ java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Running the same test from a windows machine, gives me no error. On my windows machine:

java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

The full error's stacktrace is:

javax.ws.rs.ProcessingException: java.io.IOException: Error writing to server at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:287) at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684) at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:681) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:228) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444) at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:681) at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:437) at org.glassfish.jersey.client.JerseyInvocation$Builder.put(JerseyInvocation.java:326)

....

Caused by: java.io.IOException: Error writing to server at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:666) at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:678) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:394) at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:285)

... 40 more

I can only suppose two causes for the error:

  1. the difference of the jvm version
  2. different networking settings among the two operating systems

This error comes up in specific requests with rathed large http loads. Many colleagues in various posts have suggested that this occurs during large http requests, however I have not found any post suggesting a solution or relating it to Ubuntu specifically.

Any hints?

Which would be the networking parameters affecting such functionality? How could I change/adapt them?

Would specific jvm configuration be needed?


Solution

  • The solution is on the TCP level and not on the JVM version or configuration. I have changed the my ubuntu networking settings and the error is gone. I suppose, it occured only to large HTTP requests, because the TCP windows were too small or something.

    I followed the instructions in http://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl article to set the following settings:

    net.ipv4.tcp_window_scaling = 1
    net.core.rmem_max = 16777216 
    net.ipv4.tcp_rmem = 4096 137380 16777216 
    net.ipv4.tcp_wmem = 4096      137380   16777216
    

    Please note that the error occured on an HTTP request with a load of about 90kbytes. I needed to play around with the value of the window assigned to each TCP connection (137380) in order to succeed.

    Please also note that this could have other side effects in your networking that I cannot really foresee or explain. Testing with larger window values caused delays in other requests that I cannot explain. Therefore, increasing the TCP windows size is not a suits-all solution.