Вы можете попробовать esm
.
Вот некоторые введение: https://www.npmjs.com/package/esm
«Эта ошибка может возникнуть, если локальная сетевая система прерывает соединение, например, когда WinSock закрывает установленное соединение после сбоя повторной передачи данных (приемник никогда не подтверждает данные, отправленные в гнездо потока данных).». См. эту статью MSDN . См. Также Некоторая информация о «Программе вызвана отключением соединения» .
Я видел это чаще всего, когда корпоративный брандмауэр на рабочей станции / ноутбуке мешает, он убивает соединение.
, например. У меня есть серверный процесс и клиентский процесс на одной машине. Сервер прослушивает все интерфейсы (0.0.0.0), и клиент пытается подключиться к общедоступному / домашнему интерфейсу (обратите внимание, что это не интерфейс loopback 127.0.0.1).
Если на компьютере отключена сеть (например, Wi-Fi выключен), тогда соединение формируется. Если устройство подключено к корпоративной сети (напрямую или vpn), тогда соединение формируется.
Однако, если аппарат подключен к общедоступному Wi-Fi (или к домашней сети), тогда брандмауэр ударяет по убивающим связь. В этой ситуации подключение клиента к интерфейсу loopback работает нормально, а не в домашнем / общедоступном интерфейсе.
Надеюсь, что это поможет.
Я столкнулся с той же проблемой с wireMock, одновременно высмеивая остальные вызовы API. Раньше я определял сервер следующим образом:
WireMockServer wireMockServer = null;
Но он должен быть определен, как показано ниже:
@Rule
public WireMockRule wireMockRule = new WireMockRule(8089);
Вы проверили исходный код Tomcat и источник JVM? Это может дать вам больше помощи.
Я думаю, что ваше общее мышление хорошее. Я ожидал бы ConnectException
в сценарии, с которым вы не могли соединиться. Вышеприведенное выглядит очень похоже на клиентское управление.
java.net.SocketException
вызывается при возникновении ошибки при создании или доступе к сокету (например, TCP ). Обычно это может быть вызвано, когда сервер завершил соединение (без его правильного закрытия), поэтому до получения полного ответа. В большинстве случаев это может быть вызвано проблемой таймаута (например, ответ занимает слишком много времени или сервер перегружен запросами), или клиент отправил SYN, но он не получил ACK (подтверждение завершения соединения) , Для проблем с таймаутом вы можете увеличить значение таймаута.
Исключение Socket обычно содержит подробное сообщение о проблеме.
Пример подробных сообщений:
HttpClient
, являющийся null
, не может вызвать SocketException
. Не записывать правильную длину в поток тоже нет.
– user207421
4 July 2017 в 01:09
В ситуации, описанной ниже, клиентская сторона будет вызывать такое исключение:
Серверу предлагается аутентифицировать клиентский сертификат, но клиент предоставляет сертификат, который Extended Key Usage не поддерживает аутентификацию клиента, поэтому сервер не принимает сертификат клиента, а затем закрывает соединение.
В моем случае ошибка была:
java.net.SocketException: Software caused connection abort: recv failed
Она была получена в eclipse при отладке приложения java для доступа к базе данных H2. Источником ошибки было то, что я сначала открыл базу данных с помощью SQuirreL, чтобы проверить целостность вручную. Я использовал флаг для включения нескольких подключений к одному и тому же БД (т. Е. AUTO_SERVER=TRUE
), поэтому нет проблем с подключением к БД из java.
Ошибка появилась, когда через некоторое время --it это длинный Java-процесс. Я решил закрыть SQuirreL для освобождения ресурсов. Похоже, что SQuirreL был «владельцем» экземпляра сервера БД и что он был отключен с помощью соединения SQuirreL.
Перезапуск приложения Java снова не выдало ошибку.
config
Эта ошибка произошла со мной при тестировании моей мыльной службы с клиентом SoapUI, в основном я пытался получить очень большое сообщение (> 500kb), а SoapUI закрыл соединение таймаутом.
On SoapUI перейти к:
File -> Preferences - Socket Timeout (ms)
blockquote>... и поместить большое значение, например 180000 (3 минуты) , это не будет идеальным решением для вашей проблемы, потому что файл на самом деле большой, но по крайней мере у вас будет ответ.
Я столкнулся с той же проблемой. Обычно эта ошибка возникает из-за того, что клиент закрыл свое соединение, а сервер все еще пытается писать на этом клиенте. Поэтому убедитесь, что ваш клиент имеет свое соединение открытым до тех пор, пока сервер не выполнит свой выходной поток. И еще одно: Дон не забыл закрыть входной и выходной поток.
Надеюсь, это поможет. И если вы все еще сталкиваетесь с проблемой, чем кратко расскажите о своей проблеме здесь.
Для всех, кто использует простые программы Client Server и получает эту ошибку, это проблема незакрытых (или закрытых для ранних) потоков ввода или вывода.
Мой сервер выбрасывал это исключение в течение 2 дней, и я решил его, переместив функцию разъединения с помощью:
outputStream.close();
inputStream.close();
Client.close();
. К концу строки списка. если это кому-то помогло.
Чтобы доказать, какой компонент сбой, я бы отслеживал связь TCP / IP с помощью wireshark и смотрел, кто является actaully, закрывающим порт, также могут быть релевантны таймауты.