java.io.IOException: Rohr defekt

Lesezeit: 9 Minuten

Cemos Benutzeravatar
Cemo

Wir migrieren derzeit eine Legacy-Anwendung auf Jetty. Und ich habe irgendwie eine Ausnahme bezüglich eines Rohrbruchs.

  • Java 6
  • Anlegestelle 8.1.8
  • Frühling 3.2.0

Ich versuche, eine Glassfish-Webanwendung auf Jetty zu migrieren. In unserer Testumgebung verwenden wir einen Load Balancer und alles funktioniert einwandfrei. Unsere Kunden arbeiten problemlos. 

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

Wenn ich den Stacktrace überprüfe, sehe ich, dass diese Ausnahmen immer durch eine 404-Anfrage ausgelöst werden.

org.springframework.web.servlet.DispatcherServlet.noHandlerFound(DispatcherServlet.java:1111)

  • Warum habe ich diese Ausnahme?
  • Wie kann ich diese Ausnahme lokal auf meinem Computer reproduzieren?

  • In meinem Fall ist es passiert, als ich das Popup so eingestellt habe, dass es von meinem Backend mit einer Zeitüberschreitung zum automatischen Schließen geladen wird, und es geschlossen wird, bevor das Popup geladen wird

    – Shareef

    7. Dezember 2017 um 19:16 Uhr

Der häufigste Grund, den ich für eine „kaputte Leitung“ hatte, ist, dass eine Maschine (eines Paars, das über einen Socket kommuniziert) ihr Ende des Sockets abgeschaltet hat, bevor die Kommunikation abgeschlossen war. Etwa die Hälfte davon war darauf zurückzuführen, dass das Programm, das auf diesem Socket kommunizierte, beendet wurde.

Wenn das Programm, das Bytes sendet, diese aussendet und den Socket sofort herunterfährt oder sich selbst beendet, ist es möglich, dass der Socket nicht mehr funktioniert, bevor die Bytes übertragen und gelesen wurden.

Versuchen Sie, überall dort Pausen einzulegen, wo Sie den Socket herunterfahren und bevor Sie zulassen, dass das Programm beendet wird, um zu sehen, ob das hilft.

Zu Ihrer Information: „Pipe“ und „Socket“ sind Begriffe, die manchmal synonym verwendet werden.

  • Ich weiß fast, welche Anfrage diese Ausnahme erstellt, aber es ist mir nicht gelungen, eine ähnliche Ausnahme zu erstellen. Haben Sie eine Idee, einen Rohrbruch durch Einrollen oder etwas anderes zu erzeugen?

    – Cemo

    3. April 2013 um 11:09

  • rcook hat recht, es sieht so aus, als hätte sich der Client nicht die Mühe gemacht, die Antwort vor dem Beenden vollständig zu verarbeiten. Dies kann häufig auftreten, wenn ein Benutzer eine Seite verlässt, bevor der Ladevorgang vollständig abgeschlossen ist

    – Jesse McConnell

    3. April 2013 um 11:31 Uhr

  • Ich habe festgestellt, dass mein Problem darin besteht, dass es auf der Clientseite eine Timeout-Einstellung gibt. Die Clientseite schließt die Verbindung, wenn die Wartezeit überschritten wird. Danach möchte die Serverseite die Antwort an die Clientseite weiterleiten, aber der Stream ist bereits geschlossen. Also das „Rohrbruch„Es ist ein Problem aufgetreten. Sie können die clientseitige Timeout-Einstellung anpassen, um dieses Szenario zu verhindern.

    – Max Peng

    9. März 2018 um 15:30 Uhr

  • Deshalb habe ich diese Ausnahme bis zur Warnstufe behandelt.

    – Buddha

    8. Juni 2018 um 2:28

  • Offensichtlich muss der Code, der für das Senden der Informationen verantwortlich ist, außerhalb der Kontrolle des Benutzers liegen. Wenn der Benutzer also auf eine Schaltfläche klicken und den Thread beenden kann, sind Sie der Gnade des Benutzers ausgeliefert. Ohne Ihre Anwendung zu kennen, ist es schwierig, konkrete Vorschläge zu machen, aber Sie könnten darüber nachdenken, sicherzustellen, dass sich der Code, der für den Abschluss des Socket-Versands verantwortlich ist, in einem Nicht-Daemon-Thread (oder „in einem Daemon“?) Thread befindet, d. h. eine, die nicht automatisch beendet wird, wenn die App beendet wird, damit sie den Versand abschließen kann. Dies setzt natürlich voraus, dass Sie die Kontrolle über den Absender haben …

    – bogenförmig

    9. Juni 2018 um 0:06

Ich stimme @arcy zu, das Problem liegt auf der Clientseite. In meinem Fall lag es an Nginx. Lassen Sie mich näher darauf eingehen. Ich verwende Nginx als Frontend (damit ich Last, SSL usw. verteilen kann) und verwende proxy_pass http://127.0.0.1:8080 um die entsprechenden Anfragen an Tomcat weiterzuleiten.

Es gibt einen Standardwert für die Nginx-Variable proxy_read_timeout von 60ern sollte das ausreichen, aber in einigen Spitzenmomenten kam es bei meinem Setup zu Fehlern java.io.IOException: Rohr defekt Das Ändern des Werts hilft, bis die Grundursache (60 Sekunden sollten ausreichen) behoben werden kann.

HINWEIS: Ich habe eine neue Antwort erstellt, damit ich meinen Fall etwas näher erläutern kann (es war die einzige Erwähnung dieses Fehlers, die ich nach langem Suchen im Internet gefunden habe).

Im Grunde genommen schließt Ihr Benutzer entweder den Browser-Tab oder navigiert zu einer anderen Seite, bevor die Kommunikation abgeschlossen ist. Ihr Webserver (Jetty) generiert diese Ausnahme, weil er die verbleibenden Bytes nicht senden kann. 

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)
!

Dies ist kein Fehler auf der Seite Ihrer Anwendungslogik. Das liegt einfach am Nutzerverhalten. An Ihrem Code ist per se nichts falsch.

Es gibt zwei Dinge, die Sie möglicherweise tun können:

  1. Ignorieren Sie diese spezielle Ausnahme, damit Sie sie nicht protokollieren.
  2. Machen Sie Ihren Code effizienter/gepackter, sodass er weniger Daten überträgt. (Nicht immer eine Option!)

  • Falls Sie (wie ich) einen Weg finden möchten, diesen speziellen Typ von IOException zu ignorieren (und nicht alle anderen), dann zeigt dieser Blog-Beitrag gut, wie man das in Spring MVC macht: mtyurt.net/post/…

    – Sorin Postelnicu

    8. Okt. 2018 um 16:58

Die Fehlermeldung weist darauf hin, dass der Client die Verbindung geschlossen hat, während der Server noch versucht, eine Antwort zu schreiben.

Weitere Informationen finden Sie unter diesem Link:

https://markhneedham.com/blog/2014/01/27/neo4j-org-eclipse-jetty-io-eofception-caused-by-java-io-ioException-broken-pipe/

Vimalkumar Natarajans Benutzeravatar
Vimalkumar Natarajan

Erhöhen Sie die Antwort.getBufferSize(), ermitteln Sie die Puffergröße und vergleichen Sie sie mit den Bytes, die Sie übertragen möchten!

  • Hallo, ich übe das und dies ist eine einzeilige Antwort auf diese Frage. Bietet die Antwort von Arcy wertvolle Hinweise für Sie? Wissen Sie, warum es Sinn macht, es zu ändern?

    – Vimalkumar Natarajan

    3. September 2015 um 10:02 Uhr

  • Es gibt kein bufferSize() -Methode im JDK oder eine der abweichenden Schreibweisen und „compare [thebuffer size] mit den Bytes, die Sie übertragen möchten“ ist bedeutungslos. Antwort ist Unsinn.

    – Benutzer207421

    3. Mai 2016 um 10:47

  • @VimalkumarNatarajan erwägt, dem OP einen leicht verständlichen Codeausschnitt zu hinterlassen, denn meiner Meinung nach sagt die Länge der Antwort nichts über die Antwort aus, daher ist es in Ordnung, da es für den OP hilfreich ist, wenn dies nicht der Fall ist Erwägen Sie daher, diese Antwort zu bearbeiten und schließlich zu löschen. Für den guten Willen stimmen

    – Viktor

    22. Mai 2018 um 22:36 Uhr

Zons Benutzeravatar
Zon

Möglicherweise haben Sie die Ausgabedatei nicht festgelegt.

  • Hallo, ich übe das und dies ist eine einzeilige Antwort auf diese Frage. Bietet die Antwort von Arcy wertvolle Hinweise für Sie? Wissen Sie, warum es Sinn macht, es zu ändern?

    – Vimalkumar Natarajan

    3. September 2015 um 10:02 Uhr

  • Es gibt kein bufferSize() -Methode im JDK oder eine der abweichenden Schreibweisen und „compare [thebuffer size] mit den Bytes, die Sie übertragen möchten“ ist bedeutungslos. Antwort ist Unsinn.

    – Benutzer207421

    3. Mai 2016 um 10:47

  • @VimalkumarNatarajan erwägt, dem OP einen leicht verständlichen Codeausschnitt zu hinterlassen, denn meiner Meinung nach sagt die Länge der Antwort nichts über die Antwort aus, daher ist es in Ordnung, da es für den OP hilfreich ist, wenn dies nicht der Fall ist Erwägen Sie daher, diese Antwort zu bearbeiten und schließlich zu löschen. Für den guten Willen stimmen

    – Viktor

    22. Mai 2018 um 22:36 Uhr

Benutzeravatar von arunas_t
arunas_t

Vielleicht findet jemand diese Antwort trotzdem relevant: In meinem Fall war dieser Fehler darauf zurückzuführen, dass das Datei-Upload-Limit kleiner als die hochgeladene Dateigröße war.

  • Wo ist in Ihrem Fall das Datei-Upload-Limit festgelegt? Auf der Client- oder Serverseite?

    – thermz

    19. September 2022 um 10:17 Uhr

1452760cookie-checkjava.io.IOException: Rohr defekt

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy