Ошибка java.net.SocketException: Conection reset — как исправить
В этом примере мы поговорим о java.net.SocketException. Это подкласс IOException, поэтому это проверенное исключение, которое сигнализирует о проблеме при попытке открыть или получить доступ к сокету.
Настоятельно рекомендуется использовать самый «определенный» класс исключений сокетов, который более точно определяет проблему. Стоит также отметить, что SocketException, выдаётся на экран с сообщением об ошибке, которое очень информативно описывает ситуацию, вызвавшую исключение.
Простое клиент-серверное приложение
Чтобы продемонстрировать это исключение, я собираюсь позаимствовать некоторый код из клиент-серверного приложения, которое есть в java.net.ConnectException. Он состоит из 2 потоков.
Поток 1 — SimpleServer, открывает сокет на локальном компьютере через порт 3333. Потом он ожидает установления соединения. Если происходит соединение, он создает входной поток и считывает 1 текстовую строчку, от клиента, который был подключен.
Поток номер 2 — SimpleClient, подключается к сокету сервера, открытого SimpleServer. Он отправляет одну текстовую строчку.
Получается, что 2 потока будут в разных классах, запущенных двумя разными основными методами, чтобы вызвать исключение:
Как вы можете видеть, я поместил в SimpleClient 15-секундную задержку, прежде чем попытаться отправить свое сообщение. К тому моменту, когда клиент вызывает sleep(), он уже создал соединение с сервером. Я собираюсь запустить оба потока, и после того, как клиент установит соединение, я внезапно остановлю клиентское приложение. Вот что происходит на стороне сервера:
Мы получаем исключение SocketException с сообщением «Сброс подключения». Это происходит, когда один из участников принудительно закрывает соединение без использования close().
Конечно, вы можете сделать оперативное закрытие соединения, не закрывая приложение вручную. В коде клиента, после ожидания в течение 15 секунд (или меньше), вы можете выдать новое исключение (используя throws new Exception ()), но вы должны удалить finally, иначе соединение будет нормально закрываться, и SocketException не будет сброшен.
Как решить проблему с SocketException
SocketException — это общее исключение, обозначающее проблему при попытке доступа или открытия Socket. Решение этой проблемы должно быть сделано с особой тщательностью. Вы должны всегда регистрировать сообщение об ошибке, которое сопровождает исключение.
В предыдущем примере мы видели код сообщения. Это происходит, когда один из участников принудительно закрывает соединение без использования close (). Это означает, что вы должны проверить, был ли один из участников неожиданно прерван.
Также может быть сообщение «Слишком много открытых файлов», особенно если вы работаете в Linux. Это сообщение обозначает, что многие файловые дескрипторы открыты для системы. Вы можете избежать этой ошибки, если перейдете в /etc/sysctl.conf и увеличите число в поле fs.file-max. Или попытаться выделить больше стековой памяти.
Конечно, можно встретить много других сообщений. Например, «Ошибка привязки», где ваше соединение не может быть установлено, поскольку порт не может быть привязан к сокету. В этом случае проверьте, используется ли порт и т. д. Если у вас проблема с minecraft, то в видео ниже очень просто объясняется как это решить.
java.net.SocketException: Connection reset by peer: socket w
Базовые технологии Java /
22 сен 2012 06:50
Пробовал проверять сокет перед отправкой на что только можно:
Читал, что проверить сокет можно только попробовав записать в него что то, верно глосят? Тогда у меня нет другого выхода, как тупо обработать эксепшен в моей задачи, получив что то нечто?:
А может (так у меня закрывается клиентская часть)
не посылает команду на закрытия сокета и поробовать что то типо такого:
Но я не знаю команду для закрытия, поэтому не смог проверить. И если это от части верно подскажите «куда читать» . С уважением, Роман
23 сен 2012 01:09
23 сен 2012 03:19
Попробуй отправлять данные через сокет в виде массива байтов.
24 сен 2012 16:03
RaD1KaL Возможно я не понял вашу мысль, но я не вижу смысла в данном подходе. Что он дает?
to All В итоге после добавления java windowClosing event :
в консоль сервера не сипется предыдущий эксепшен, вообще тишина, что не может не радовать. Но сервер по прежнему считает что сокет открыт и обрабатывает это условие:
Тут (код на стороне сервера):
Как так получается?
Так же в клиент стал сыпаться эксепшен:
Попробовал как написал ниже, не сработало. ..может глупо, но это к тому что не ленился, искал выход.. Экшен на закрытие (код на стороне клиента):
Метод где сыпется эксепшен (код на стороне клиента):
Как этот эксепшен обработать?
С уважением, Роман.
25 сен 2012 02:46
Роман, в наше время код возврата по сути ни на что уже не влияет. Предполагается что он потом может обрабатываться другими программами, например командным интерпретатором. Главное что значения отличные от нуля обозначают что программа завершилась с ошибкой.
Может еще стоит посмотреть на процесс разрыва соединения через сниффер? Вроде wireshark.
27 сен 2012 21:48
30 сен 2012 07:24
Не совсем понимаю что там искать?! Чего то у меня не получается, нету ни чего что бы хоть как то дало мне понять что это мои запросы. Возможно сказывается что и сервер и клиент пока на одной машине, для тестирования, и пакеты идут через петлю? Хотя IP для работы указан как на сетевой карте. ..имею поверхностное представления что такое wireshark, и не юзал для определенных целей ни разу..
Подскажите как? Так же через сниффер? Конечно метод пытается считать данные из уже закрытого сокета, я же его закрыл, повешав события на крестик. см.выше
to All Как я понял это так(эксепшеном) выходится из цикла в методе. Может есть что то более корректное, чем не работающий этот код: ..повторюсь, что я передаю false в isActive при закрытие клиентского окна..
..код привел, что бы с акцентировать внимание на методе где идет эксепшен.. Но он таки сыпет мне эксепшен к клиентскую консоль..
И! Почему, после закрытия клиентского приложения, передав команду на закрытия сокета, сервер после обработки данных вернувшись класс сокета с данными для отправки, считает что сокет запущен? ..проходит проверка. см.выще..
Что вызывает мое java. net. SocketException: сброс соединения?
мы видим часто java.net.SocketException: Connection reset ошибки в наших журналах для компонента, который вызывает стороннюю веб-службу, которая отправляет SMS-сообщения.
наше приложение написано на Java и работает на базе Tomcat 5.5. Его написали подрядчики, которых у нас больше нет. Текущая команда не имеет реального опыта Java, и мы не уверены, где Connection reset ошибка на самом деле и откуда, и как идти об отладке.
проблема кажется полностью прерывистой, и не связаны с сообщениями, которые мы пытаемся отправить.
любые предложения о том, что типичные причины этого исключения могут быть, и как мы могли бы продолжить, приветствуются.
весь стек вызовов включен ниже для полноты.
( com.companyname.mtix.sms это наша составляющая)
строка нашего кода, из которой выбрасывается исключение, является последней строкой в приведенном ниже фрагменте кода.
13 ответов:
javadoc для SocketException утверждает, что это
брошенный, чтобы указать, что есть ошибка в базовом протоколе, таком как ошибка TCP
в вашем случае похоже, что соединение было закрыто сервером подключения. Это может быть проблема с запросом, который вы отправляете, или проблема в их конце.
чтобы помочь отладке вы можете посмотреть на использование такого инструмента, как Wireshark для просмотра фактического сетевой пакет. Кроме того, есть ли альтернативный клиент для вашего кода Java, который вы могли бы использовать для тестирования веб-службы? Если это было успешно, это может указывать на ошибку в коде Java.
Как вы используете Commons HTTP Client посмотрите на общее руководство по ведению журнала HTTP-клиента. Это расскажет вам, как зарегистрировать запрос на уровне HTTP.
ошибка происходит на вашей стороне а не с другой стороны. Если другая сторона сбросит соединение, то сообщение об исключении должно сказать:
причиной является соединение внутри HttpClient несвежее. Проверка устаревшего соединения для SSL не устраняет эту ошибку. Решение: сбросьте свой клиент и воссоздайте его.
при попытке доступа к веб-службам, развернутым на сервере Glassfish3, может потребоваться настроить параметры пула http-потоков. Это фиксированные SocketExceptions у нас было, когда многие параллельные потоки вызывали веб-службу.
перейти в консоль администратора
перейдите к «конфигурации»->»конфигурация сервера»->»пулы потоков»->»http-thread-pool».
изменить параметр «максимальный размер пула потоков» с 5 до 32
изменить параметр «мин Размер пула потоков» от 2 до 16
Перезапустить Glassfish.
в моем случае это было потому, что мой кот был установлен с недостаточным maxHttpHeaderSize для особо сложного запроса SOLR.
надеюсь, что это поможет кому-то там!
Я тоже наткнулся на эту ошибку. В моем случае проблема была в том, что я использовал JRE6, с поддержкой TLS1.0. Сервер поддерживал только TLS1.2, поэтому эта ошибка была выдана.
Я получаю эту ошибку все время и считают это нормальным.
Это происходит, когда одна сторона пытается читать, когда другая сторона уже повесил трубку. Таким образом в зависимости от протокола это может или не может обозначить проблему. Если мой клиентский код специально указывает серверу, что он собирается повесить трубку, то клиент и сервер могут повесить трубку одновременно, и это сообщение не произойдет.
способ реализации моего кода для клиента просто повесьте трубку, не попрощавшись. Затем сервер может поймать ошибку и игнорировать ее. В контексте HTTP я считаю, что один уровень протокола позволяет более одного запроса на соединение, а другой-нет.
таким образом, вы можете видеть, как потенциально одна сторона может продолжать висеть на другой. Я сомневаюсь, что ошибка, которую вы получаете, имеет какое-либо пиратское отношение, и вы можете просто поймать ее, чтобы она не заполняла ваши файлы журнала.
исключение означает, что сокет был неожиданно закрыт с другой стороны. Поскольку вы вызываете веб-службу, этого не должно произойти — скорее всего, вы отправляете запрос, который вызывает ошибку в веб-службе.
попробуйте записать весь запрос в этих случаях, и посмотреть, если вы заметили что-нибудь необычное. В противном случае свяжитесь с поставщиком веб-услуг и отправьте им свой зарегистрированный проблемный запрос.
эта ошибка возникает на стороне сервера, когда клиент закрыл соединение до того, ответ может быть возвращен через сокет. В сценарии веб-приложения не все из них опасны, так как они могут быть созданы вручную. Например, путем выхода из браузера до получения ответа.
Я знаю, что этот поток немного стар, но хотел бы добавить мои 2 цента. У нас была такая же ошибка «сброса соединения» сразу после нашего одного из выпусков.
первопричина была, наша apache сервер был сбит для развертывания. Весь наш сторонний трафик проходит через apache и мы получали ошибку сброса соединения из-за того, что он был вниз.
Это старый поток, но я столкнулся с java.net.SocketException: Connection reset вчера.
в серверном приложении были изменены настройки регулирования, чтобы разрешить только 1 соединение за раз! Таким образом, иногда звонки проходили, а иногда нет. Я решил проблему, изменив настройки регулирования.
Я тоже получал именно эту ошибку: Connection reset by peer . Исключение был поднят по шаблону остальных источников при выполнении postForObject() метод. Для меня проблемой был слишком длинный HTTP URL запрос. Поэтому сначала проверьте, является ли созданный URL-адрес тем, что он должен быть, и если ваш сервер действительно должен иметь возможность обрабатывать запросы такой длины, просто перейдите к конфигурации сервера и поднимите допустимую длину URL-запросов по умолчанию.
это решило проблему для меня, но помните: приложение может не работать в некоторых интернет-браузерах, особенно старых, так как они имеют фиксированную максимальную длину URL-запросов.
надеюсь, что это помогает.
Я получил эту ошибку, когда текстовый файл, который я пытался прочитать, содержал строку, которая соответствовала антивирусной подписи на нашем брандмауэре.
я столкнулся с этой проблемой. Это вызвано заблокированными сеансами в базе данных, которые связаны с таблицами, которые вы собираетесь изменить через Webservice.
найти заблокированные идентификаторы сеанса:
это должно дать вам подсказки о том, что таблица заблокирована, но еще не завершает изменения.
I have to write a multithreaded client and server using Java’s socket api. Both the client and server are multithreaded, so the server can handle multiple connections and the client can test the server’s ability to handle connections.
I am having a couple, probably related issues. One, occasionally one of the client threads will throw
Which from its position means the server is closing its socket before the client is done reading from it. How can I prevent this?
Also, even counting the threads which throw the Socket closed exception, it seems that not all the server threads are sending their output. For example, 23 of the 30 server threads will send their output, but only 22 of the client threads will receive anything. The communications are obviously getting lost somewhere, how do I prevent this?
Создан 10 окт. 11 2011-10-10 15:18:57 Tick-Tock
On first glance, I would pose the following: (1) are you flushing your output streams on the server end (to make sure there isn’t data waiting to the written), (2) on lines 55-57 of ‘ClientThread.java’, I don’t think you need to close the streams separately from closing the socket. Try NOT doing that (on both client and server sides) and see what happens. Finally (3) check out the JavaDoc for the ‘close()’ method, and see if anything here sheds light on what’s going on: http://download.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#close%28%29 in terms of premature closure. – jefflunt 10 окт. 11 2011-10-10 15:28:36
Yes, I am calling flush() every time either side sends data. – Tick-Tock 10 окт. 11 2011-10-10 15:43:27
But, you set the PrintWriter to autoflush with the final parameter so it’s already do that for you. The flush() isn’t needed because PrintWriter set in auto flush will call flush() after every print*() method call. – chubbsondubs 10 окт. 11 2011-10-10 15:47:34
1 ответ
Your problem is this in ClientThread:
That means all threads are sharing the same socket instance for all instances of ClientThread. That means your sockets are going to get out of sync with the state of the conversation. Your conversation is:
Client connects
Client sends request
Client waits for response
Client receives response
Client close socket (should be done by each).
Server waits for client
Server reads request
Server processes command
Server sends response
Server closes sockets
However, you have 30 conversations all trying to be in different states at the same time, and the server and client can’t keep track of them. First thread creates the socket sends a request moves to state 2, while it’s waiting another threads creates another socket, writes it to moves to state 2, when the First thread wakes up it then starts talking over the new socket that was created by thread 2 which hasn’t finished processing it’s command. Now a third starts and overwrites that reference again, so on and so on. The first command won’t ever be read because it lost the reference to the original socket when thread 2 overwrote it, and it starts reading thread 2’s command and spitting it out. Once thread 1 makes it to the close statements it closes the socket down while other threads are trying to read/write to it, and bang the exception is tossed.
Essentially each ClientThread should create their own socket instance, and then each conversation can occur independently than the other conversations going on. Think if you wrote your client to be single threaded. Then started up two separate processes (run your Java app twice). Each process would create their own socket and each conversation would work independently. What you have now is one socket with 30 threads shouting commands over one megaphone to the server. Work can’t proceed in an orderly fashion when everyone is shouting over the same megaphone.
So in summary change remove static modifier from socket member in ClientThread, and it should start working pretty well.
Just as an aside never release this code into the world. It has serious security problems because clients can execute any command at the security level your server process is running. So very easily anyone could own your machine or capture your account with relatively ease. Executing commands like that from the client means they could send:
And capture your password hashes for example. I think you are just learning, but I felt like you should be alerted to what you’re doing to be on the safe side.
Another thing is the server is only closing down sockets if the conversation went as expected. You really should move the close() calls into the finally block on the try block you have. Otherwise if a client closes its socket prematurely (it happens) then your server will leak sockets and eventually it will run out of sockets in the OS.
Another thing you might want to explore is using Thread pools on the server instead of newing up a thread for every new connection you get. In your simple example it’s easy to play around with this, and it works. However, if you were building a real server a thread pool has two major contributions. 1. creating threads has an overhead associated with it so you can get some performance response time by have a thread sitting around waiting to service incoming requests. You can save yourself sometime to respond to clients. 2. More importantly a physical computer can’t endlessly create threads. If you had lots of clients say 1000+ your machine would be hard pressed to answer all of those using 1000 threads. A thread pool means you create max number of threads, say 50 threads, and each thread will be used multiple times to process each request. As new connections come in they wait for a thread to free up before being processed. If you get too many connections coming in the clients will timeout as opposed to destroying your machine requiring a reboot. It allows you to get through more requests faster while keeping you from dying should too many connections come in at once.
Finally, a close socket exception can happen for many valid reasons. Often if a client just shuts down in the middle of a conversation the server will get that exception. It’s best to properly shutdown and clean up yourself when that happens. You can’t ever prevent it is my point. You just have to respond to it.
Создан 10 окт. 11 2011-10-10 15:46:32 chubbsondubs
