«Ошибка: запись на сервер» - только на ubuntu

Question

Я использую файл jar, реализующий пользовательскую функциональность, которая использует трикотаж как клиент REST (версия 2.22.1). Хотя все работает нормально для нескольких вызовов, для определенного HTTP-вызова я получаю сообщение «Ошибка: запись на сервер», , но только при работе в ubuntu.

Ошибка при запуске модульного теста на двух моих компьютерах разработки ubuntu. Мои компьютеры развития являются Ubuntu 16,04 с 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) 

Запуск же тест из машины окна, не дает мне ошибку. На моем окна машины:

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) 

StackTrace В Ошибка переполнения заключается в следующем:

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

Я могу только предположить две причины ошибки:

1. разность Jvm версии
2. различные сетевые настройки между двумя операционными системами

Эта ошибка возникает при определенных запросах с повышенными большими нагрузками HTTP. Многие коллеги из разных должностей предположили, что это происходит во время больших HTTP-запросов, однако я не нашел ни одной публикации, предлагающей решение или связавшего его с Ubuntu специально.

Любые подсказки?

Какими будут сетевые параметры, влияющие на такие функции? Как я могу их изменить или адаптировать?

Может понадобиться конкретная конфигурация jvm?

Answer 1

Решение находится на уровне TCP, а не на версии JVM или конфигурации. Я изменил настройки сети ubuntu, и ошибка исчезла. Я предполагаю, что это происходило только для больших HTTP-запросов, потому что окна TCP были слишком маленькими или что-то еще.

Я следовал инструкциям в статье http://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl установить следующие параметры:

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 

Пожалуйста, обратите внимание, что ошибка произошла по запросу HTTP с нагрузкой около 90kbytes. Мне нужно было поиграть со значением окна, назначенного каждому TCP-соединению (137380), чтобы добиться успеха.

Обратите также внимание, что это может иметь другие побочные эффекты в вашей сети, которые я не могу предвидеть или объяснить. Тестирование с большими значениями окна вызывало задержки в других запросах, которые я не могу объяснить. Таким образом, увеличение размера окон TCP не является решением для всех желаний.