Вопросы Теги

Исключение Android Socket java.net.SocketException: программное обеспечение вызвало прерывание соединения [дубликат]

Держите ссылки на все объекты DirectionsRenderer и установите для всех своих свойств карты значение null. 

function requestDirections(start, end, routeToDisplay, main_route) {
    // remove any old renderers from the map
    for (var i = 0; i < directionsRenderers.length; i++) {
        directionsRenderers[i].setMap(null);
    }
    // clear out the directionsRenderers array
    directionsRenderers = [];

    var request = {
        origin: start,
        destination: end,
        travelMode: google.maps.DirectionsTravelMode.DRIVING,
        provideRouteAlternatives: main_route
    };

    directionsService.route(request, function (result, status) {
        if (status == google.maps.DirectionsStatus.OK) {
            if (main_route) {
                var rendererOptions = getRendererOptions(true);
                for (var i = 0; i < result.routes.length; i++) {
                    renderDirections(result, rendererOptions, i);
                }
            } else {
                var rendererOptions = getRendererOptions(false);
                renderDirections(result, rendererOptions, routeToDisplay);
            }
        }
    });
}

function renderDirections(result, rendererOptions, routeToDisplay) {

    if (routeToDisplay == 0) {
        var _colour = '#00458E';
        var _strokeWeight = 4;
        var _strokeOpacity = 1.0;
        var _suppressMarkers = false;
    } else {
        var _colour = '#ED1C24';
        var _strokeWeight = 4;
        var _strokeOpacity = 0.7;
        var _suppressMarkers = false;
    }

    // create new renderer object
    var directionsRenderer = new google.maps.DirectionsRenderer({
        draggable: false,
        suppressMarkers: _suppressMarkers,
        polylineOptions: {
            strokeColor: _colour,
            strokeWeight: _strokeWeight,
            strokeOpacity: _strokeOpacity
        }
    })
    directionsRenderer.setMap(map);
    directionsRenderer.setDirections(result);
    directionsRenderer.setRouteIndex(routeToDisplay);

    // push new renderer onto directionsRenderers array;
    directionsRenderers.push(directionsRenderer);
}

доказательство концепции fiddle

133
задан Eran Medan 24 January 2010 в 10:52
поделиться

12 ответов

«Эта ошибка может возникнуть, если локальная сетевая система прерывает соединение, например, когда WinSock закрывает установленное соединение после сбоя повторной передачи данных (приемник никогда не подтверждает данные, отправленные в гнездо потока данных).». См. эту статью MSDN . См. Также Некоторая информация о «Программе вызвана отключением соединения» .

47
ответ дан user207421 18 August 2018 в 11:58
поделиться
  • 1
    WSAECONNABORTED - Понятное объяснение – Mat Gessel 21 November 2012 в 04:18
  • 2
    @MatGessel Эта статья просто повторяет путаницу и добавляет некоторые из ее собственных. WSAECONNABORTED - это код ошибки Winsock, поэтому не может быть объяснений Беркли. Ситуация, описанная о HTTP-сервере, создаст ECONNRESET, а не WSAECONNABORTED. – user207421 5 December 2012 в 00:13
  • 3
    @EJP, я получаю это исключение при отправке / записи (outs.write (audioBytes);) byte [] в OutputStream. Когда звук работает, и во время воспроизведения, если пользователь нажимает на любое другое меню (которое отправляет запрос сервера), я получил ту же ошибку на консоли. так можно ли игнорировать это исключение? – Amogh 10 March 2015 в 07:47
  • 4
    ECONNRESET создается, когда в буфере отправки нет данных, когда есть WSAECONNABORTED. Возможно, статья добавляет в ваш путаницу EJP, но в остальном совершенно точна. – rustyx 29 March 2015 в 17:01
  • 5
    @rustyx Все три источника, упомянутые здесь, указывают, что они производятся с ошибками ACK. Если у вас есть источник для вашего собственного заявления, просите его. – user207421 27 May 2015 в 05:52
  • 6
    – Derek Bennett 20 March 2017 в 15:05

Я видел это чаще всего, когда корпоративный брандмауэр на рабочей станции / ноутбуке мешает, он убивает соединение.

, например. У меня есть серверный процесс и клиентский процесс на одной машине. Сервер прослушивает все интерфейсы (0.0.0.0), и клиент пытается подключиться к общедоступному / домашнему интерфейсу (обратите внимание, что это не интерфейс loopback 127.0.0.1).

Если на компьютере отключена сеть (например, Wi-Fi выключен), тогда соединение формируется. Если устройство подключено к корпоративной сети (напрямую или vpn), тогда соединение формируется.

Однако, если аппарат подключен к общедоступному Wi-Fi (или к домашней сети), тогда брандмауэр ударяет по убивающим связь. В этой ситуации подключение клиента к интерфейсу loopback работает нормально, а не в домашнем / общедоступном интерфейсе.

Надеюсь, что это поможет.

9
ответ дан akjoshi 18 August 2018 в 11:58
поделиться
  • 1
    Межсетевые экраны предотвращают соединения. Речь идет о сбросе существующего соединения. – user207421 22 July 2016 в 23:28

Я столкнулся с той же проблемой с wireMock, одновременно высмеивая остальные вызовы API. Раньше я определял сервер следующим образом: 

WireMockServer wireMockServer = null;

Но он должен быть определен, как показано ниже: 

@Rule 
public WireMockRule wireMockRule = new WireMockRule(8089);
-3
ответ дан Bojan B 18 August 2018 в 11:58
поделиться
  • 1
    Это приведет к NullPointerException, а не к этой проблеме. – user207421 4 July 2017 в 01:10

Вы проверили исходный код Tomcat и источник JVM? Это может дать вам больше помощи.

Я думаю, что ваше общее мышление хорошее. Я ожидал бы ConnectException в сценарии, с которым вы не могли соединиться. Вышеприведенное выглядит очень похоже на клиентское управление.

2
ответ дан Brian Agnew 18 August 2018 в 11:58
поделиться
  • 1
    Да, я проверил. Спасибо, что источники Tomcat не содержат перестановки предложения. – Eran Medan 24 January 2010 в 11:00
  • 2
    Нет, он не проверял источник Tomcat AND источника JVM. – Stephen C 24 January 2010 в 12:32
  • 3
    Или, если он проверил источник JVM, он не проверил все это. – Stephen C 24 January 2010 в 13:12
  • 4
    @Ehrann - строка сообщения, скорее всего, в родных источниках. Но вы также должны проверить журнал событий. ИМО, последнее, вероятно, будет более информативным. – Stephen C 26 January 2010 в 22:39
  • 5
    Эта строка сообщений поступает из операционной системы. – user207421 13 October 2011 в 00:15

java.net.SocketException вызывается при возникновении ошибки при создании или доступе к сокету (например, TCP ). Обычно это может быть вызвано, когда сервер завершил соединение (без его правильного закрытия), поэтому до получения полного ответа. В большинстве случаев это может быть вызвано проблемой таймаута (например, ответ занимает слишком много времени или сервер перегружен запросами), или клиент отправил SYN, но он не получил ACK (подтверждение завершения соединения) , Для проблем с таймаутом вы можете увеличить значение таймаута.

Исключение Socket обычно содержит подробное сообщение о проблеме.

Пример подробных сообщений:

  • Программное обеспечение вызвало прерывание соединения: recv не удалось. Ошибка указывает на попытку отправить сообщение, и соединение было прервано вашим сервером. Если это произошло при подключении к базе данных, это может быть связано с использованием несовместимого драйвера Connector / J JDBC . Возможное решение. Убедитесь, что в вашем CLASSPATH есть соответствующие библиотеки / драйверы.
  • Программное обеспечение вызвало прерывание соединения: connect. Это может произойти, если есть проблема с подключением к пульту дистанционного управления. Например, из-за проверки на вирусы, отклоняющей удаленные почтовые запросы . Возможное решение: проверьте службу проверки вирусов, блокирует ли он порт для исходящих запросов на соединения.
  • Программное обеспечение вызвало прерывание соединения: ошибка записи сокета. Возможное решение: убедитесь, что вы пишете правильную длину байтов в потоке. Поэтому дважды проверьте, что вы отправляете. См. Этот поток .
  • Сброс соединения с помощью одноранговой сети: ошибка записи сокета / Соединение прерывается ошибкой записи пира: сокет Приложение не проверяет, было ли время ожидания подключения включено на стороне сервера. Возможное решение: убедитесь, что HttpClient не имеет значения null перед чтением из соединения. E13222_01
  • Соединение сброшено одноранговым узлом. Соединение было завершено сервером (сервером).
  • Сброс соединения. Соединение было либо прекращено клиентом, либо закрыто сервером в конце соединения из-за запроса с запросом. См.: Что вызывает мой java.net.SocketException: Сброс соединения?
3
ответ дан Community 18 August 2018 в 11:58
поделиться
  • 1
    Только один из этих 6 пунктов фактически отвечает на вопрос неправильно. Некоторые другие неверны. Приложение не может 'проверять, было ли время ожидания подключения на стороне сервера.' HttpClient, являющийся null, не может вызвать SocketException. Не записывать правильную длину в поток тоже нет. – user207421 4 July 2017 в 01:09

В ситуации, описанной ниже, клиентская сторона будет вызывать такое исключение:

Серверу предлагается аутентифицировать клиентский сертификат, но клиент предоставляет сертификат, который Extended Key Usage не поддерживает аутентификацию клиента, поэтому сервер не принимает сертификат клиента, а затем закрывает соединение.

-1
ответ дан lrnzcig 18 August 2018 в 11:58
поделиться
  • 1
    Этот ответ неверен. В случае, если вы описали SSLException, будет выбрано. – James K Polk 16 May 2018 в 00:21

Закрытое соединение в другом клиенте

В моем случае ошибка была: 

java.net.SocketException: Software caused connection abort: recv failed

Она была получена в eclipse при отладке приложения java для доступа к базе данных H2. Источником ошибки было то, что я сначала открыл базу данных с помощью SQuirreL, чтобы проверить целостность вручную. Я использовал флаг для включения нескольких подключений к одному и тому же БД (т. Е. AUTO_SERVER=TRUE), поэтому нет проблем с подключением к БД из java.

Ошибка появилась, когда через некоторое время --it это длинный Java-процесс. Я решил закрыть SQuirreL для освобождения ресурсов. Похоже, что SQuirreL был «владельцем» экземпляра сервера БД и что он был отключен с помощью соединения SQuirreL.

Перезапуск приложения Java снова не выдало ошибку.

config

  • Windows 7
  • Eclipse Kepler
  • SQuirreL 3.6
  • org.h2. Драйвер версии 1.4.192
0
ответ дан manuelvigarcia 18 August 2018 в 11:58
поделиться

Эта ошибка произошла со мной при тестировании моей мыльной службы с клиентом SoapUI, в основном я пытался получить очень большое сообщение (> 500kb), а SoapUI закрыл соединение таймаутом.

On SoapUI перейти к:

File -> Preferences - Socket Timeout (ms)

... и поместить большое значение, например 180000 (3 минуты) , это не будет идеальным решением для вашей проблемы, потому что файл на самом деле большой, но по крайней мере у вас будет ответ.

0
ответ дан Marco 18 August 2018 в 11:58
поделиться

Я столкнулся с той же проблемой. Обычно эта ошибка возникает из-за того, что клиент закрыл свое соединение, а сервер все еще пытается писать на этом клиенте. Поэтому убедитесь, что ваш клиент имеет свое соединение открытым до тех пор, пока сервер не выполнит свой выходной поток. И еще одно: Дон не забыл закрыть входной и выходной поток.

Надеюсь, это поможет. И если вы все еще сталкиваетесь с проблемой, чем кратко расскажите о своей проблеме здесь.

1
ответ дан Nirav Chhatrola 18 August 2018 в 11:58
поделиться
  • 1
    хороший Ответ ......... – Bhavin Patel 30 June 2016 в 11:46
  • 2
    @BhavinChhatrola Нет, неверный ответ. Описанная ситуация дает «сброс соединения с помощью одноранговой сети», а не ошибку в вопросе. – user207421 4 July 2017 в 01:02

Для всех, кто использует простые программы Client Server и получает эту ошибку, это проблема незакрытых (или закрытых для ранних) потоков ввода или вывода.

2
ответ дан PRO_gramista 18 August 2018 в 11:58
поделиться
  • 1
    Нет, это не так. Это будет представлять собой утечку сокета, что в конечном итоге приведет к истощению FD. – user207421 27 May 2015 в 05:48

Мой сервер выбрасывал это исключение в течение 2 дней, и я решил его, переместив функцию разъединения с помощью: 

outputStream.close();
inputStream.close();
Client.close();

. К концу строки списка. если это кому-то помогло.

-1
ответ дан Sefi Erlich 18 August 2018 в 11:58
поделиться

Чтобы доказать, какой компонент сбой, я бы отслеживал связь TCP / IP с помощью wireshark и смотрел, кто является actaully, закрывающим порт, также могут быть релевантны таймауты.

4
ответ дан stacker 18 August 2018 в 11:58
поделиться
  • 1
    Никто не закрывает порт. Операционная система прерывает соединение. – user207421 19 November 2014 в 10:42
  • 2
    @EJP Я видел, как это происходит, когда перегружается и заканчивается память. Я не уверен, что ОС закрывает соединение, но JVM идет не так. – Zee 10 April 2015 в 22:39
  • 3
    @Zee Существует разница между закрытием порта, который отображается как FIN в Wireshark, и прерывание соединения, а это не так. – user207421 27 May 2015 в 05:47
Другие вопросы по тегам:

Похожие вопросы: