java - ¿Cómo solucionar el error "Error de escritura de socket reset"?

servlets socketexception

Question

Cuando estoy leyendo el contenido del archivo del servidor, devuelve el siguiente mensaje de 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

y mi programa de servlets es

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

¿Cómo resolver este problema?

Answer 1

El socket ha sido cerrado por el cliente (navegador).

Un error en tu código:

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

El último paquete leído, luego escribir puede tener una longitud <4096, por lo que sugiero:

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

No es tu pregunta, pero es mi respuesta ... ;-)

Answer 2

La forma correcta de ''resolver'' es cerrar la conexión y olvidarse del cliente. El cliente ha cerrado la conexión mientras usted todavía estaba escribiendo, por lo que no quiere conocerlo, así que eso es todo, ¿no es así?

Answer 3

Parece que tu problema puede estar surgiendo en

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

donde podría entrar en un bucle infinito para no avanzar el desplazamiento (que es 0 siempre en la llamada). Tratar

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

que intentará por defecto leer hasta outputByte.length en el byte[] . De esta forma no tendrás que preocuparte por el offset. Ver el método de lectura de FileInputStrem.

Answer 4

Tengo la misma excepción y, en mi caso, el problema estaba en un proceso de renegociación. De hecho, mi cliente cerró una conexión cuando el servidor intentó cambiar una suite de cifrado. Después de excavar, parece que en el proceso de renegociación jdk 1.6 actualización 22 está deshabilitado por defecto . Si sus restricciones de seguridad pueden hacer esto, intente habilitar la renegociación no segura estableciendo la propiedad del sistema sun.security.ssl.allowUnsafeRenegotiation en true . Aquí hay alguna información sobre el proceso:

La renegociación de sesión es un mecanismo dentro del protocolo SSL que permite al cliente o al servidor desencadenar un nuevo protocolo de enlace SSL durante una comunicación SSL en curso. La renegociación se diseñó inicialmente como un mecanismo para aumentar la seguridad de un canal SSL en curso, al activar la renovación de las claves criptográficas utilizadas para asegurar ese canal. Sin embargo, esta medida de seguridad no es necesaria con los algoritmos criptográficos modernos. Además, un servidor puede usar la renegociación para solicitar un certificado de cliente (para realizar la autenticación del cliente) cuando el cliente intenta acceder a recursos específicos y protegidos en el servidor.

Además, hay una excelente publicación sobre este tema en detalles y escrita en un lenguaje comprensible (IMHO).

Answer 5

Tuve el mismo problema con una pequeña diferencia:

Se levanta la excepción en el momento de enrojecer.

Es un problema diferente de . La breve explicación fue una configuración de encabezado de respuesta incorrecta:

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

A pesar del contenido de datos de respuesta sin comprimir.

Así que la conexión fue cerrada por el navegador.