Cemo
Actualmente estamos migrando una aplicación heredada a Jetty. Y de alguna manera tengo una excepción con respecto a una tubería rota.
- Java 6
- Embarcadero 8.1.8
- Primavera 3.2.0
Estoy tratando de migrar una aplicación web de Glassfish a Jetty. En nuestro entorno de prueba, usamos un balanceador de carga y todo funciona bien. Nuestros clientes están trabajando sin ningún problema.
WARN [2013-04-03 13:34:28,963] com.myapp.bbb.config.MvcDefaultConfig$1: Handler execution resulted in exception
! org.eclipse.jetty.io.EofException: null
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914)
! at org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:798)
! at org.eclipse.jetty.server.AbstractHttpConnection.completeResponse(AbstractHttpConnection.java:642)
! at org.eclipse.jetty.server.Response.complete(Response.java:1234)
! at org.eclipse.jetty.server.Response.sendError(Response.java:404)
! at org.eclipse.jetty.server.Response.sendError(Response.java:416)
! at org.springframework.web.servlet.DispatcherServlet.noHandlerFound(DispatcherServlet.java:1111)
! at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:898)
! at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
! at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:915)
! at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:811)
! at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
! at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:796)
! at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
! at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1336)
! at com.magnetdigital.maggy.dropwizard.head2get.Head2GetFilter.doFilter(Head2GetFilter.java:22)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
! at com.yammer.dropwizard.servlets.ThreadNameFilter.doFilter(ThreadNameFilter.java:29)
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
! at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
! at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
! at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
! at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
! at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
! at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
! at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
! at com.yammer.metrics.jetty.InstrumentedHandler.handle(InstrumentedHandler.java:200)
! at org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:275)
! at com.yammer.dropwizard.jetty.BiDiGzipHandler.handle(BiDiGzipHandler.java:123)
! at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
! at org.eclipse.jetty.server.Server.handle(Server.java:365)
! at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
! at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
! at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
! at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
! at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
! at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
! at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
! at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298)
! at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
! at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
! at java.lang.Thread.run(Thread.java:662)
Caused by: ! java.io.IOException: Broken pipe
! at sun.nio.ch.FileDispatcher.write0(Native Method)
! at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
! at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:69)
! at sun.nio.ch.IOUtil.write(IOUtil.java:26)
! at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
! at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:293)
! at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.flush(BlockingChannelConnector.java:253)
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:850)
!... 44 common frames omitted
Cuando verifico el seguimiento de la pila, he visto que estas excepciones se desencadenan siempre por una solicitud 404.
org.springframework.web.servlet.DispatcherServlet.noHandlerFound(DispatcherServlet.java:1111)
- ¿Por qué tengo esta excepción?
- ¿Cómo puedo reproducir esta excepción en mi máquina localmente?
La razón más común que he tenido para una “tubería rota” es que una máquina (de un par que se comunica a través de un zócalo) cerró su extremo del zócalo antes de que se completara la comunicación. Aproximadamente la mitad de ellos se debieron a que el programa que se comunicaba en ese socket había terminado.
Si el programa que envía los bytes los envía e inmediatamente apaga el socket o se cierra solo, es posible que el socket deje de funcionar antes de que los bytes hayan sido transmitidos y leídos.
Intente poner pausas en cualquier lugar donde esté cerrando el socket y antes de permitir que el programa finalice para ver si eso ayuda.
FYI: “tubería” y “enchufe” son términos que a veces se usan indistintamente.
-
Casi conozco la solicitud que está creando esta excepción, pero no pude tener éxito para crear una similar. ¿Tienes alguna idea para generar una tubería rota por rizo o algo más?
– Cemo
3 de abril de 2013 a las 11:09
-
rcook es correcto, parece que el cliente no se molestó en consumir por completo la respuesta antes de salir… a menudo puede obtener esto cuando un usuario navega fuera de una página antes de que haya terminado de cargarse por completo
– jesse mcconnell
03/04/2013 a las 11:31
-
Descubrí que mi problema es que hay una configuración de tiempo de espera en el lado del cliente, el lado del cliente cerrará la conexión cuando se exceda el tiempo de espera. Después de eso, el lado del servidor quiere enviar la respuesta al lado del cliente, pero la transmisión ya está cerrada. Entonces el “tuberia rota” Ocurrió un problema. Puede ajustar la configuración de tiempo de espera del lado del cliente para eliminar este escenario.
–Max Peng
9 de marzo de 2018 a las 3:30
-
Así que he manejado esta excepción para advertir el nivel.
– Buda
8 de junio de 2018 a las 2:28
-
Claramente, el código responsable de enviar la información debe estar fuera del control del usuario, es decir, si el usuario puede hacer clic en un botón y hacer que ese hilo se cierre, entonces estás a merced del usuario. Sin conocer su aplicación, es difícil hacer sugerencias específicas, pero podría pensar en asegurarse de que el código responsable de completar el envío del socket esté en un subproceso que no sea un demonio (¿o esté “en un demonio”?), es decir, uno que no se cierra automáticamente cuando la aplicación finaliza, para que pueda terminar de enviar. Esto supone que tienes control sobre el remitente, por supuesto…
– arcy
9 de junio de 2018 a las 0:06
Estoy de acuerdo con @arcy, el problema está en el lado del cliente, en mi caso fue por nginx, permítanme explicarlo, estoy usando nginx como interfaz (para poder distribuir la carga, ssl, etc.) y usando proxy_pass http://127.0.0.1:8080 para reenviar las solicitudes apropiadas a tomcat.
Hay un valor predeterminado para la variable nginx proxy_read_timeout de 60 eso debería ser suficiente, pero en algunos momentos pico mi configuración fallaba con el java.io.IOException: tubería rota cambiar el valor ayudará hasta que se pueda solucionar la causa raíz (60s debería ser suficiente).
NOTA: Hice una nueva respuesta para poder ampliar un poco más mi caso (fue la única mención que encontré sobre este error en Internet después de buscar mucho)
Básicamente, lo que sucede es que su usuario está cerrando la pestaña del navegador o navegando a una página diferente antes de que se complete la comunicación. Su servidor web (Jetty) genera esta excepción porque no puede enviar los bytes restantes.
org.eclipse.jetty.io.EofException: null
! at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914)
! at org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:798)
! at org.eclipse.jetty.server.AbstractHttpConnection.completeResponse(AbstractHttpConnection.java:642)
!
Esto no es un error en el lado de la lógica de su aplicación. Esto se debe simplemente al comportamiento del usuario. No hay nada malo en su código per se.
Hay dos cosas que puede hacer:
- Ignore esta excepción específica para no registrarla.
- Haga que su código sea más eficiente/empaquetado para que transmita menos datos. (¡No siempre es una opción!)
-
En caso de que desee (como yo) encontrar una manera de ignorar este tipo específico de IOException (y no ignorar todos los demás), esta publicación de blog hace un buen trabajo al mostrar cómo hacerlo en Spring MVC: mtyurt.net/post/…
– Sorin Postelnicu
8 oct 2018 a las 16:58
El mensaje de error sugiere que el cliente ha cerrado la conexión mientras el servidor aún intenta escribir una respuesta.
Consulte este enlace para obtener más detalles:
Vimalkumar Natarajan
aumente la respuesta. getBufferSize() obtenga el tamaño del búfer y compárelo con los bytes que desea transferir.
-
Hola, estoy practicando esto, y esta es una respuesta de una sola línea para esta pregunta. ¿La respuesta de arcy le proporciona información valiosa? ¿Sabes el punto para modificarlo?
–Vimalkumar Natarajan
3 de septiembre de 2015 a las 10:02
-
No hay
bufferSize()método en el JDK, o cualquiera de las variantes ortográficas, y ‘comparar [thebuffer size] con los bytes que desea transferir’ no tiene sentido. La respuesta es una tontería.– usuario207421
3 mayo 2016 a las 10:47
-
@VimalkumarNatarajan considere dejar un fragmento de código fácil de seguir por el OP, para mí, la longitud de la respuesta no dice nada sobre la respuesta, por lo que está bien, parece que es útil para el OP, si ese no es el caso , así que considere editar y eventualmente eliminar esta respuesta. Votando por la buena voluntad
– Víctor
22 mayo 2018 a las 22:36
Zona
Es posible que no haya configurado el archivo de salida.
-
Hola, estoy practicando esto, y esta es una respuesta de una sola línea para esta pregunta. ¿La respuesta de arcy le proporciona información valiosa? ¿Sabes el punto para modificarlo?
–Vimalkumar Natarajan
3 de septiembre de 2015 a las 10:02
-
No hay
bufferSize()método en el JDK, o cualquiera de las variantes ortográficas, y ‘comparar [thebuffer size] con los bytes que desea transferir’ no tiene sentido. La respuesta es una tontería.– usuario207421
3 mayo 2016 a las 10:47
-
@VimalkumarNatarajan considere dejar un fragmento de código fácil de seguir por el OP, para mí, la longitud de la respuesta no dice nada sobre la respuesta, por lo que está bien, parece que es útil para el OP, si ese no es el caso , así que considere editar y eventualmente eliminar esta respuesta. Votando por la buena voluntad
– Víctor
22 mayo 2018 a las 22:36
arunas_t
Tal vez alguien encuentre relevante esta respuesta: en mi caso, este error se debió a que el límite de carga de archivos era más pequeño que el tamaño del archivo cargado.
-
¿Dónde está establecido el límite de carga de archivos en su caso? ¿Del lado del cliente o del servidor?
– thermz
19 de septiembre de 2022 a las 10:17
en mi caso, sucedió cuando configuré la ventana emergente para que se cargara desde mi backend con el tiempo de espera para cerrarse automáticamente, y se cierra antes de cargar la ventana emergente
– compartir
7 de diciembre de 2017 a las 19:16