Как решить "Соединение reset по ошибке peer: socket write"? - программирование

Как решить "Соединение reset по ошибке peer: socket write"?

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

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();

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Это не ваш вопрос, но это мой ответ...; -)

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

response.setHeader( "Content-Encoding", "gzip" );

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

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