«Сброс соединения» при использовании SOAP

Question

У меня есть служба REST, а некоторые клиенты получают ошибку «Сброс соединения». Но SOAP не имеет гражданства, поэтому почему он просто не перезаписывает и не отправляет запрос? Он фактически отправляет несколько сообщений в моем случае использования, но самый первый не удается, и это просто для получения некоторых данных конфигурации с сервера. Нужно ли это настраивать? Должен ли клиент программно попытаться отправить сообщение повторно? Некоторые пользователи несколько раз пытались использовать один и тот же результат.

Это никогда не случалось в последние годы, но теперь я получаю сообщения об этой проблеме.
Клиент использует в реализации javax.xml.ws.Service, а не только сырое гнездо. Но хотя я использую JAX, я получаю ошибку низкого уровня. Он завернут WebServiceException, но это не помогает мне решить эту проблему. Все клиенты используют Java 8. Это либо обновление 66, либо обновление 74.

Я не могу воспроизвести проблему самостоятельно, у меня есть только файлы журналов от пользователей.

Вот полный трассировки стека:

javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset 
    at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source) 
    at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source) 
    at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source) 
    at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source) 
    at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source) 
    at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source) 
    at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source) 
    at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source) 
    at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source) 
    at com.sun.xml.internal.ws.client.Stub.process(Unknown Source) 
    at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source) 
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source) 
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source) 
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source) 
    at com.sun.proxy.$Proxy31.getLimits(Unknown Source) 
    at xxxxxxxxxxxxx.SOAPServerAdapter.connect(Unknown Source) 
    at xxxxxxxxxxxxxxxxxxxx(Unknown Source) 
    at java.lang.Thread.run(Unknown Source) 
Caused by: java.net.SocketException: Connection reset 
    at java.net.SocketInputStream.read(Unknown Source) 
    at java.net.SocketInputStream.read(Unknown Source) 
    at sun.security.ssl.InputRecord.readFully(Unknown Source) 
    at sun.security.ssl.InputRecord.read(Unknown Source) 
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) 
    at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source) 
    at sun.security.ssl.AppInputStream.read(Unknown Source) 
    at java.io.BufferedInputStream.fill(Unknown Source) 
    at java.io.BufferedInputStream.read1(Unknown Source) 
    at java.io.BufferedInputStream.read(Unknown Source) 
    at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) 
    at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) 
    at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) 
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) 
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) 
    at java.net.HttpURLConnection.getResponseCode(Unknown Source) 
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source) 
    ... 18 more 

Answer 1

Проверьте нагрузку на сервер. Похоже, сервер закрывает соединения из-за нагрузки - exception on web-service call

Answer 2

Оказалось, что речь идет о IPv4 и IPv6. У меня недостаточно знаний, чтобы дать отличный ответ, но я могу опубликовать здесь то, что они сказали мне. Возможно, это помогает другим разработчикам/пользователям, которые имеют одинаковую проблему.

Таким образом, у некоторых клиентов есть неожиданные сбрасывания соединения, и дело не в загрузке сервера, как обычно.

Если ISP клиента пытается уйти от IPv4, он предоставит каждому пользователю уникальный IPv6-адрес (обратите внимание, что провайдер может сделать это постепенно). У них на самом деле нет IPv4-адреса для каждого клиента, кроме IPv4, используемого локально, поскольку большинство из них по-прежнему используют что-то вроде 192.168.0.0/24 для своей локальной сети.

Вместо классического IPv4 они используют некоторые transaction mechanism (например, Dual-Stack Lite). Эти клиенты не имеют прямого доступа к Интернету IPv4. Поэтому, если ваш сервер поддерживает только IPv4, они могут столкнуться с аналогичными проблемами, возникающими при использовании прокси. Они инкапсулируют пакеты IPv4 в пакеты IPv6 для некоторых частей связи. Из Википедии: «Исходный пакет IPv4 восстанавливается, а NAT выполняется по пакету IPv4 и направляется в общедоступный IPv4-Интернет».

Я действительно не знаю, что здесь происходит. Возможно, у NAT заканчиваются адреса/порты или что-то в этом роде. Или процесс занимает слишком много времени, когда соединение сбрасывается каким-то узлом, который задействован в связи.

Итак, есть две вещи, чтобы сделать:

1. Проинформировать провайдера об этих проблемах. Вероятно, они помогут вам определить точную проблему и помочь своим клиентам, чтобы они могли воспользоваться вашим сервисом. Для этого вам нужно знать провайдера пользователей, у которых есть проблема с «сбросом соединения». Отправьте их на номер https://www.whoismyisp.org/ или аналогичный сайт.
2. Переход на IPv6 как можно скорее. Сервер может одновременно использовать обе версии протокола.