Как решить «Сброс соединения с помощью ошибки peer: socket write error»?

Когда я читаю содержимое файла с сервера, он возвращает следующее сообщение об ошибке:

Caused by: java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(Unknown Source) at java.net.SocketOutputStream.write(Unknown Source) at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:366) at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:240) at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:119) at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:192) at org.apache.coyote.Response.doWrite(Response.java:504) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383) ... 28 more 

и моя программа сервлета

  response.setContentType("application/octet-stream"); response.setHeader("Content-Disposition","attachment;filename="+filename); FileInputStream in = new FileInputStream(new File(filepath)); ServletOutputStream output=response.getOutputStream(); byte[] outputByte=new byte[4096]; while(in.read(outputByte,0,4096)!=-1){ output.write(outputByte,0,4096);//error indicates in this line } in.close(); output.flush(); output.close(); в  response.setContentType("application/octet-stream"); response.setHeader("Content-Disposition","attachment;filename="+filename); FileInputStream in = new FileInputStream(new File(filepath)); ServletOutputStream output=response.getOutputStream(); byte[] outputByte=new byte[4096]; while(in.read(outputByte,0,4096)!=-1){ output.write(outputByte,0,4096);//error indicates in this line } in.close(); output.flush(); output.close(); 

Как решить эту проблему?

У меня такое же исключение, и в моем случае проблема была в процессе пересмотра. На самом деле мой клиент закрыл соединение, когда сервер попытался изменить набор шифров. После копания появляется сообщение о том, что в процессе обновления jdk 1.6 22 по умолчанию отключен . Если ваши ограничения безопасности могут это сделать, попробуйте включить небезопасное пересмотр, установив для sun.security.ssl.allowUnsafeRenegotiation значение true . Вот некоторая информация о процессе:

Пересмотр сеанса – это механизм в протоколе SSL, который позволяет клиенту или серверу инициировать новое SSL-соединение во время непрерывной связи SSL. Первоначальная реорганизация была разработана как механизм повышения безопасности текущего канала SSL путем запуска обновления криптографических ключей, используемых для защиты этого канала. Однако эта мера безопасности не требуется с современными криптографическими алгоритмами. Кроме того, повторное соглашение может использоваться сервером для запроса сертификата клиента (для проверки подлинности клиента), когда клиент пытается получить доступ к определенным защищенным ресурсам на сервере.

Кроме того, есть отличная статья об этой проблеме в деталях и написана на (ИМХО) понятном языке.

Сокет был закрыт клиентом (браузером).

Ошибка в коде:

 byte[] outputByte=new byte[4096]; while(in.read(outputByte,0,4096)!=-1){ output.write(outputByte,0,4096); } в byte[] outputByte=new byte[4096]; while(in.read(outputByte,0,4096)!=-1){ output.write(outputByte,0,4096); } 

Последний пакет считывается, тогда запись может иметь длину <4096, поэтому я предлагаю:

 byte[] outputByte=new byte[4096]; int len; while(( len = in.read(outputByte, 0, 4096 )) > 0 ) { output.write( outputByte, 0, len ); } 

Это не ваш вопрос, но это мой ответ … 😉

Правильный способ «решить» это закрыть соединение и забыть о клиенте. Клиент закрыл соединение, пока вы все еще пишете его, поэтому он не хочет вас знать, так оно и есть, не так ли?

Кажется, ваша проблема может возникнуть в

while(in.read(outputByte,0,4096)!=-1){

где он может перейти в бесконечный цикл, чтобы не продвигать смещение (которое всегда равно 0). Пытаться

while(in.read(outputByte)!=-1){

который по умолчанию попытается прочитать upto outputByte.length в byte[] . Таким образом, вам не нужно беспокоиться о смещении. См. Метод чтения FileInputStrem

У меня была та же проблема с небольшой разницей:

Исключение было поднято в момент промывки

Это другая проблема stackoverflow . Краткое объяснение было неправильной настройкой заголовка ответа:

response.setHeader («Content-Encoding», «gzip»);

несмотря на несжатый контент данных ответа.

Таким образом, соединение было закрыто браузером.