Java net socketexception connection reset что делать - TurboComputer.ru
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд (пока оценок нет)
Загрузка...

Java net socketexception connection reset что делать

Java net socketexception connection reset что делать

Мы видим частые, но прерывистые ошибки java.net.SocketException: Connection reset в наших журналах. Мы не уверены, откуда на самом деле происходит ошибка Connection reset , и как приступить к отладке.

Проблема, по-видимому, не связана с сообщениями, которые мы пытаемся отправить. Обратите внимание, что сообщение не connection reset by peer .

Любые предложения о том, какие типичные причины этого исключения могут быть, и как мы могли бы продолжить?

Вот репрезентативный стек trace ( com.companyname.mtix.sms – это наш компонент):

Наш компонент-это веб-приложение, работающее под управлением Tomcat, которое вызывает стороннюю веб-службу, которая отправляет сообщения SMS, так бывает. Строка нашего кода, из которой выбрасывается исключение, является последней строкой в приведенном ниже фрагменте кода.

15 Ответов

Javadoc для SocketException утверждает, что это

Брошенный, чтобы указать, что есть ошибка в базовом протоколе, таком как ошибка TCP

В вашем случае кажется, что соединение было закрыто серверным концом соединения. Это может быть проблема с запросом, который вы отправляете, или проблема в их конце.

Чтобы помочь отладке, вы можете посмотреть на использование инструмента, такого как Wireshark , для просмотра фактических сетевых пакетов. Кроме того, есть ли альтернативный клиент для вашего кода Java, который вы могли бы использовать для тестирования веб-службы? Если это было успешно, это может указывать на ошибку в коде Java.

При использовании Commons HTTP Client ознакомьтесь с общим руководством по ведению журнала клиента HTTP . Это покажет вам, как зарегистрировать запрос на уровне HTTP.

Эта ошибка происходит на вашей стороне и NOT с другой стороны. Если другая сторона сбросит соединение, то сообщение об исключении должно сказать:

Причина в том, что соединение внутри HttpClient устарело. Проверка устаревшего соединения для SSL не устраняет эту ошибку. Решение: дамп вашего клиента и воссоздать.

При попытке доступа к веб-службам, развернутым на сервере Glassfish3, может потребоваться настроить параметры http-thread-pool. Это исправлено SocketExceptions у нас было, когда многие параллельные потоки вызывали веб-службу.

  1. Перейти к admin console
  2. Перейдите к “Configurations” – > “конфигурация сервера” – > “пулы потоков” – > “http-thread-pool”.
  3. Изменить настройки “Max Thread Pool Size” от 5 до 32
  4. Изменить настройки “Min Thread Pool Size” от 2 до 16
  5. Перезапустить Glassfish.

Я тоже наткнулся на эту ошибку. В моем случае проблема заключалась в том, что я использовал JRE6 с поддержкой TLS1.0 . Сервер поддерживал только TLS1.2, поэтому эта ошибка была вызвана.

В моем случае это было связано с тем, что мой Tomcat был установлен с недостаточным maxHttpHeaderSize для особенно сложного запроса SOLR.

Надеюсь, это поможет кому-то там!

Я получаю эту ошибку все время и считаю ее нормальной.

Это происходит, когда одна сторона пытается читать, когда другая сторона уже повесила трубку. Таким образом, в зависимости от протокола это может обозначать или не обозначать проблему . Если мой клиентский код специально указывает серверу, что он собирается повесить трубку, то и клиент, и сервер могут одновременно повесить трубку, и это сообщение не произойдет.

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

Таким образом, вы можете видеть, как потенциально одна сторона может продолжать висеть на другой. Я сомневаюсь, что ошибка, которую вы получаете, имеет какое-либо пиратское отношение, и вы можете просто поймать ее, чтобы она не заполняла ваши файлы журнала.

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

Исключение означает, что сокет был неожиданно закрыт с другой стороны. Поскольку вы вызываете веб-службу, этого не должно произойти – скорее всего, вы отправляете запрос, который вызывает ошибку в веб-службе.

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

Я знаю, что эта нить немного устарела, но хотела бы добавить свои 2 цента. У нас была такая же ошибка “connection reset” сразу после нашего одного из выпусков.

Основная причина заключалась в том, что наш сервер apache был сбит для deployment. Весь наш сторонний трафик проходит через apache , и мы получаем ошибку сброса соединения из-за того, что он не работает.

Это старая тема, но вчера я столкнулся с java.net.SocketException: Connection reset .

В серверном приложении были изменены настройки регулирования, чтобы разрешить только 1 соединение одновременно! Таким образом, иногда звонки проходили, а иногда нет. Я решил проблему, изменив настройки регулирования.

Я получал эту ошибку, потому что порт, к которому я пытался подключиться, был закрыт.

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

FWIW, я получал эту ошибку, когда я случайно делал запрос GET к конечной точке, которая ожидала запроса POST. Предположительно, это был именно тот конкретный способ решения проблемы серверов.

Я получал именно эту ошибку тоже: Connection reset by peer . Исключение вызывалось шаблоном Spring REST при запуске метода postForObject() . Для меня проблемой был слишком длинный HTTP URL запрос. Поэтому сначала проверьте, является ли URL произведенным тем, чем он должен быть, и, если ваш сервер действительно должен быть в состоянии обрабатывать запросы такой длины, просто перейдите к конфигурации сервера и поднимите разрешенную по умолчанию длину URL запросов.

Это решило проблему для меня, но имейте в виду: приложение может не работать в некоторых интернет-браузерах, особенно старых, поскольку они имеют фиксированную максимальную длину запросов URL.

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

Я столкнулся с этой проблемой. Это вызвано заблокированными сеансами в базе данных, которые связаны с таблицами, которые вы собираетесь изменить через Webservice.

Найдите заблокированный сеанс IDs:

это должно дать вам подсказки о том, какая таблица заблокирована, но еще не завершила модификацию.

Читайте также:  Преобразование презентации в видео онлайн

Затем удалите его в v$session :

(99 например.)

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

Мы начали получать эту ошибку недавно. работает уже более четырех лет. Что-то изменилось на сайте DEMO? Вызвано: java.net.SocketException вызов.

Как только сценарий входа выполняется с несколькими пользователями, я не вижу проблемы сброса соединения, тогда как, когда то же самое выполняется 100 пользователями, ” java.net.SocketException.

*hi, я хочу сделать telnet подключение некоторых устройств . я могу подключить устройства cisco и juniper, однако, когда команда send quit выходит из устройств huawei, мой код вызывает исключение в.

Что вызывает мое java.net.SocketException: сброс соединения?

Мы наблюдаем частые java.net.SocketException: Connection reset ошибки java.net.SocketException: Connection reset в наших журналах для компонента, который вызывает стороннюю веб-службу, которая отправляет SMS-сообщения.

Наше приложение написано на Java и работает поверх Tomcat 5.5. Это было написано подрядчиками, которых больше нет с нами. Нынешняя команда не имеет реального опыта работы с Java, и мы не уверены, откуда на самом деле происходит ошибка Connection reset и как отлаживать.

Похоже, что проблема полностью периодическая и не связана с сообщениями, которые мы пытаемся отправить.

Любые предложения о том, какими могут быть типичные причины этого исключения и как мы можем действовать, приветствуются.

Весь стек вызовов включен ниже для полноты.

( com.companyname.mtix.sms является нашим компонентом)

редактировать

Строка нашего кода, из которой генерируется исключение, является последней строкой во фрагменте кода ниже.

15 ответов

Javadoc для SocketException утверждает, что это

Брошенный, чтобы указать, что есть ошибка в базовом протоколе, таком как ошибка TCP

В вашем случае кажется, что соединение было закрыто серверным концом соединения. Это может быть проблема с отправляемым вами запросом или проблема с его окончанием.

Для облегчения отладки вы можете использовать инструмент, например Wireshark, для просмотра реальных сетевых пакетов. Кроме того, есть ли альтернативный клиент к вашему коду Java, который вы могли бы использовать для тестирования веб-службы? Если это было успешно, это может указывать на ошибку в коде Java.

Поскольку вы используете HTTP-клиент Commons, обратите внимание на Руководство по ведению журнала общего HTTP-клиента . Это скажет вам, как зарегистрировать запрос на уровне HTTP.

Эта ошибка происходит на вашей стороне, а не на другой стороне. Если другая сторона сбросила соединение, то сообщение об исключении должно сказать:

Причина в том, что соединение внутри HttpClient . Проверка устаревшего соединения для SSL не устраняет эту ошибку. Решение: сбросьте ваш клиент и воссоздайте.

Если вы испытываете это при попытке получить доступ к веб-службам, развернутым на сервере Glassfish3, вы можете настроить параметры пула http-thread. Это исправило исключения SocketException, которые были у нас, когда многие параллельные потоки вызывали веб-сервис.

  1. Перейти в консоль администратора
  2. Перейдите к «Конфигурациям» -> «Конфигурация сервера» -> «Пулы потоков» -> «http-thread-pool».
  3. Измените настройку «Максимальный размер пула потоков» с 5 на 32
  4. Измените настройку “Минимальный размер пула потоков” с 2 на 16
  5. Перезагрузите Glassfish.

Я тоже наткнулся на эту ошибку. В моем случае проблема заключалась в том, что я использовал JRE6 с поддержкой TLS1.0 . Сервер поддерживает только TLS1.2, поэтому была выдана эта ошибка.

В моем случае это было связано с тем, что для моего Tomcat был задан недостаточный maxHttpHeaderSize для особенно сложного запроса SOLR.

Надеюсь, это поможет кому-то там!

Я все время получаю эту ошибку и считаю ее нормальной.

Это происходит, когда одна сторона пытается прочитать, когда другая сторона уже повесила трубку. Таким образом, в зависимости от протокола это может обозначать или не обозначать проблему . Если мой клиентский код специально указывает серверу, что он собирается повесить трубку, то и клиент, и сервер могут повесить трубку одновременно, и это сообщение не произойдет.

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

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

Исключение означает, что сокет был неожиданно закрыт с другой стороны. Поскольку вы вызываете веб-сервис, этого не должно происходить – скорее всего, вы отправляете запрос, который вызывает ошибку в веб-сервисе.

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

что – notifyutil:: java net socketexception connection reset

Что вызывает мой java.net.SocketException: сброс соединения? (8)

В javadoc для SocketException указано, что это

Брошено, чтобы указать, что в базовом протоколе есть ошибка, такая как ошибка TCP

В вашем случае кажется, что соединение было закрыто серверным концом соединения. Это может быть проблемой с запросом, который вы отправляете, или с вопросом по их окончании.

Чтобы помочь отладке, вы можете посмотреть на использование такого инструмента, как Wireshark, для просмотра фактических сетевых пакетов. Кроме того, есть альтернативный клиент для вашего Java-кода, который вы могли бы использовать для тестирования веб-сервиса? Если это было успешно, это может указывать на ошибку в коде Java.

Поскольку вы используете Commons HTTP Client, посмотрите общий протокол ведения журнала HTTP-клиентов . Это покажет вам, как регистрировать запрос на уровне HTTP.

Мы часто наблюдаем java.net.SocketException: Connection reset ошибки java.net.SocketException: Connection reset в наших журналах для компонента, который вызывает сторонний веб-сервис, отправляющий SMS-сообщения.

Наше приложение написано на Java и работает поверх Tomcat 5.5. Это было написано контрагентами, которых больше нет у нас. Текущая команда не имеет реального опыта Java, и мы не уверены в том, откуда на самом деле происходит ошибка Connection reset , и как идти об отладке.

Проблема, как представляется, полностью прерывистая и не связана с сообщениями, которые мы пытаемся отправить.

Любые предложения о том, какие типичные причины этого исключения могут быть и как мы можем продолжать, приветствуются.

Читайте также:  Преобразование XML в XLS

Полный комплект вызовов приведен ниже для полноты.

( com.companyname.mtix.sms – наш компонент)

редактировать

Строка нашего кода, на которую исключается исключение, – это последняя строка в фрагменте кода ниже.

В моем случае это произошло потому, что мой Tomcat был установлен с недостаточным maxHttpHeaderSize для особо сложного запроса SOLR.

Надеюсь, это поможет кому-то!

Исключение означает, что сокет неожиданно закрыт с другой стороны. Поскольку вы вызываете веб-службу, это не должно происходить – скорее всего, вы отправляете запрос, который вызывает ошибку в веб-службе.

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

Эта ошибка происходит на вашей стороне, а НЕ с другой стороны. Если другая сторона сбросит соединение, тогда сообщение об исключении должно сказать:

Причина в том, что соединение внутри HttpClient . Проверка устаревшего соединения для SSL не устраняет эту ошибку. Решение: сбросьте свой клиент и заново создайте.

Я знаю, что эта ветка немного старая, но хотелось бы добавить мои 2 цента. У нас была такая же ошибка «сброса соединения» сразу после нашего одного из релизов.

Основная причина заключалась в том, что наш apache сервер был отключен для развертывания. Весь наш сторонний трафик проходит через apache и мы получаем ошибку сброса соединения из-за ее отсутствия.

Я получаю эту ошибку все время и считаю ее нормальной.

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

Способ, которым я реализую свой код, – это заставить клиента просто повесить трубку, не попрощавшись. Затем сервер может поймать ошибку и проигнорировать ее. В контексте HTTP я считаю, что один уровень протокола позволяет более одного запроса на соединение, а другой – нет.

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

Я столкнулся с этой проблемой. Это вызвано заблокированными сеансами в базе данных, которые связаны с таблицами, которые вы собираетесь изменять через Webservice.

Найти заблокированные идентификаторы сеанса:

это должно дать вам подсказки о том, какая таблица заблокирована, но еще не завершила модификацию.

Затем удалите его в v$session :

(Например, 99 ).

Я тоже наткнулся на эту ошибку. В моем случае проблема заключалась в использовании JRE6 с поддержкой TLS1.0 . Сервер поддерживал только TLS1.2, поэтому эта ошибка была выбрана.

Java.net.ConnectException: Connection timed out: no further information — Решение

При попытке подключения к серверу «Майнкрафт» пользователь может столкнуться с сообщением «Java.net.ConnectException: Connection timed out: no further information». Появление данного сообщения обычно сигнализирует о возникновении различного рода сетевых проблем при получении доступа к игровому серверу, из-за чего желание пользователя насладиться игровыми мирами «Майнкрафт» остаётся нереализованным. Ниже я разберу суть данной дисфункции, опишу её причины, а также поясню, как исправить ошибку Java.net.ConnEctexception на вашем ПК.

Месседж о возникшей ошибке

Connection timed out: no further information – особенности дисфункции

В переводе текст данного сообщения звучит примерно как «Сетевой сбой Java. Время соединения истекло: дальнейшая информация отсутствует».

Указанная ошибка Java.net.ConnectException обычно возникает во время подключения к серверу игры «Майнкрафт», но также фиксировались спорадические случаи появления данной ошибки при работе других продуктов, использующих «Java» (к примеру, на «Azure notification hub»).

Появление проблемы «Java.net.ConnectException: Connection timed out: no further information» имеет следующие причины:

  • Пользователь использует нестабильное сетевое соединение с медленным интернетом;
  • На ПК пользователя установлена устаревшая версия «Java»;
  • Пользователь пользуется устаревшей версией «Майнкрафт»;
  • Наблюдаются сбои в работе игрового сервера, к которому пробует подключиться пользователь (ресурс не доступен, проходят технические работы и др.);
  • Антивирус или брандмауэр блокирует подключения к игровому серверу;
  • Пользователь использует динамический IP;
  • Пользовательский роутер работает некорректно.

Как исправить «Java.net.ConnectException: Connection timed out»

Существуют несколько способов избавиться от ошибки Java.net.ConnectException. Рассмотрим их по порядку:

  • Перезагрузите ваш PC. В некоторых случаях данный простой метод позволял решить ошибку java.net.connectexception connection refused;
  • Установите на ПК свежую версию «Java». Довольно частой причиной рассматриваемой проблемы является устаревшая версия «Java» на пользовательском ПК. Перейдите в Панель управления, затем в «Программы», там найдите «Java» и кликните на неё. После появления окна её настроек перейдите на вкладку «Update», нажмите там на кнопку «Update Now», и установите в системе требуемые обновления.

Данную процедуру необходимо провести как на вашей машине, так и на машине того пользователя, с которым вы собираетесь играть в «Майнкрафт» по сети;

Обновите вашу версию «Ява»

    Внесите «Майнкрафт» в исключения брандмауэра и антивируса на вашем ПК. Запустите Панель управления, перейдите в «Система и безопасность», там найдите «Брандмауэр Виндовс» и кликните на него. В открывшемся окне настроек брандмауэра слева сверху выберите опцию «Разрешения взаимодействия…». Выберите данную опцию

В открывшемся окне разрешённых для внешнего подключения программ найдите программы с упоминанием «Java», и поставьте им галочки для разрешения подключения (поможет кнопка «Изменить параметры»). Нажимаем на «Ок» для сохранения результата, перезагружаемся и пробуем подключиться к серверу. С антивирусом необходимо проделать аналогичные операции, внеся «Java» и «Майнкрафт» в его исключения;

  • Попробуйте альтернативный сервер. Если подключения к конкретному серверу невозможно, тогда вполне вероятно, что у него наблюдаются временные проблемы в работе. Рекомендую попробовать альтернативный сервер, или подождать некоторое время, пока работоспособность начального сервера восстановиться;
  • Создайте сервер на другой машине. Если вы создаёте сервер, к которому подключается другой знакомый вам пользователь, тогда рекомендуется поменять базовый компьютер для создания сервера. То есть сервер должен создать уже другой пользователь, а вы подключитесь к нему. Часто это позволяло решить проблему net.ConnectException на пользовательском компьютере;
  • Используйте статистический IP-адрес. Если у вас есть возможность, рекомендуется использовать официальный (белый) IP-адрес, полученный через провайдера (обычно данная услуга имеет платный характер);
  • Установите на ваш ПК (гаджет) свежую версию «Майнкрафт». Обычно необходимо, чтобы версии игры на сервере и на вашем ПК (гаджете) соответствовали друг другу;

    Читайте также:  Восстановление флешек Verbatim

    Установите самую свежую версию программы

  • Избавьтесь от имеющихся модов к игре. Если вы используете какие-либо моды «Майнкрафт», рекомендуется удалить их, оставив само тело игры;
  • Перезагрузите ваш роутер. Отключите ваш роутер, подождите полминуты, а затем включите его обратно;
  • Обратитесь за консультацией к провайдеру. По различным причинам некоторые провайдеры блокируют доступ к некоторым серверам. Узнайте, не ваш ли это случай, и не является ли ваш провайдер причиной возникновения данной проблемы.
  • JBossDeveloper

    I hope someone can help me to understand following problem. We use JBoss 4.2.3 with JBoss Remoting 2.2.2.SP8 and JDK 1.6.0.07. We use Linux on the server side and Windows on the client side. We have a Swing client which connects to JBoss and invokes methods on stateless session beans. We use EJB3 stateless session beans. From time to time our users get following exception:

    Our configuration of the DefaultEjb3Connector looks like this:

    The client has following jars in its classpath:

    ejb3-persistence.jar
    hibernate-annotations.jar
    hibernate-client.jar
    jnp-client.jar
    jboss-common-client.jar
    jbosssx-client.jar
    jboss-ejb3-client.jar
    jboss-aop-jdk50-client.jar
    jboss-aspect-jdk50-client.jar
    jboss-remoting.jar
    jboss-serialization.jar
    jboss-transaction-client.jar
    concurrent.jar
    jboss-j2ee.jar
    jbossmq-client.jar
    jboss-ejb3x.jar

    We get this exception also with the default configuration of DefaultEjb3Connector. If the user retries his last action everything seems to work again. But as I said from time to time this exception occurs and we just don’t know what may be the cause for this problem. We tested the configuration of our routers and firewalls and everything is properly configured and work as expected. The problem occurs only with our client which connects to JBoss. All other applications work without problems.

    I hope some of you may explain, what may cause this exception.

    Thanks in advance and best regards,
    Andrej

    • 13558 Просмотры
    • Метки: нет (добавить)
    1. Re: java.net.SocketException: Connection reset

    When the exception is thrown, Remoting has just created a new socket and is trying to create an ObjectInputStream, the constructor for which tries to read a stream header. While it’s waiting on the stream header, it is informed that the server has closed the socket, as indicated by “java.net.SocketException: Connection reset”.

    The question is, then, what is going on at the server? One possibility, if the server is very busy, is that all of the worker threads are in use and the server tries to interrupt one to reuse it. If that’s the case, then increasing the size of the worker thread pool might alleviate the problem. In fact, I see you have already increased it from the default size (300) to 400. Did that reduce the frequency of the exception?

    It would be very useful to see what’s going on at the server by setting the log level for Remoting to TRACE. You can do that by adding

    By the way, I see that you’ve also added

    to the EJB3 Connector configuration. If you did that to try to solve this problem, it was a good guess but not relevant to the problem I see in the stacktrace. Setting “socket.check_connection” to “true” will enable an extra round trip communication when the Remoting client tries to reuse a connection from the connection pool. But the problem in the stacktrace occurs when a new connection is being created. If that’s the only reason for enabling connection checking, you might want to take it out, since it will introduce extra latency and network traffic.

    Let me know what happens with the server log.

    • Мне нравится (0)
    • Действия
    2. Re: java.net.SocketException: Connection reset

    thanks for your quick answer.

    The question is, then, what is going on at the server? One possibility, if the server is very busy, is that all of the worker threads are in use and the server tries to interrupt one to reuse it. If that’s the case, then increasing the size of the worker thread pool might alleviate the problem. In fact, I see you have already increased it from the default size (300) to 400. Did that reduce the frequency of the exception?

    No, it did not reduced the frequency of the exception.

    It would be very useful to see what’s going on at the server by setting the log level for Remoting to TRACE.

    We have already enabled tracing. But we were not able to find the cause for this problem by analyzing the log file. Maybe you will see something. Here is an excerpt from the log file (I’m sorry for the long post. I was not able to figure out how to attach a file to the message.):

    • Мне нравится (0)
    • Действия
    3. Re: java.net.SocketException: Connection reset

    Upps, it was not the full reply.

    Two user got this exception at 16:40:47. Small implementation detail: We use in our application Hibernate Search. When an user types something in a search field, we start searching in a background thread. When the user continues to type in the search field, we start another thread and interrupt the first one when it is not finished. Hence the client may invoke one and the same method of a session bean multiple times in a minute. But the exception occurs not only on search. It occurs also when invoking other methods.

    .
    If that’s the only reason for enabling connection checking, you might want to take it out, since it will introduce extra latency and network traffic.

    Yes, this was our guess. Thanks for the tip. We will take it out.

    Thanks in advance and best regards,
    Andrej

    Ссылка на основную публикацию
    Adblock
    detector