Google Groups | Thomas Sun | 1 month ago
  1. 0

    Frequent "PageTransportTimeoutException: Encountered too many errors talking to a worker node"

    Google Groups | 1 month ago | Thomas Sun
  2. 0

    GitHub comment 1216#157919836

    GitHub | 11 months ago | wenerme Broken pipe
  3. Speed up your debug routine!

    Automated exception search integrated into your IDE

  4. 0

    We are using Server-Sent Events to allow our client application to listen to events raised by our Jersey server. This works great. We have a requirement for our server to have an accurate list of currently-connected SSE callers (instances of our client application). To this end, our server sends a tiny message to each client (via eventOutput.write) once every five seconds. If our client is shut down while SSE-connected, or if the remote computer is powered off while SSE-connected, our server's eventOutput.write call correctly throws the ClientAbortException/SocketException exception shown below. That's perfect: we catch the exception, and mark that client as no longer connected. The problem: there are two cases where calling eventOutput.write to a no-longer-connected computer does NOT throw an exception: 1) if the Ethernet cable of the remote computer is disconnected while the client is SSE-connected, and 2) if the network adapter in the remote computer is turned off (e.g., by an administrator) while the client is SSE-connected. In these two cases, eventOutput.write does not throw an exception. We can call eventOutput.write to the remote computer every five seconds for hours and no exception is thrown. This makes it impossible to detect that the remote computer is no longer connected. To sum up, there are four cases: 1) Client software is shut down: eventOutput.write() correctly throws an exception. 2) Computer running client software is powered down: eventOutput.write() correctly throws an exception. 3) Etherhet cable is disconnected from computer running client software: eventOutput.write does not detect broken connection. 4) Network adapter on computer running client software is turned off: eventOutput.write does not detect broken connection. Here is the (good/useful) exception we get in cases where eventOutput.write DOES throw the exception we want: {code} org.apache.catalina.connector.ClientAbortException: null at org.apache.catalina.connector.OutputBuffer.doFlush( ~[catalina.jar:7.0.53] at org.apache.catalina.connector.OutputBuffer.flush( ~[catalina.jar:7.0.53] at org.apache.catalina.connector.CoyoteOutputStream.flush( ~[catalina.jar:7.0.53] at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.flush( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.message.internal.CommittingOutputStream.flush( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.server.ChunkedOutput$ ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.server.ChunkedOutput$ ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.internal.Errors.process( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.internal.Errors.process( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.process.internal.RequestScope.runInScope( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.server.ChunkedOutput.flushQueue( ~[jaxrs-ri-2.13.jar:2.13.] at org.glassfish.jersey.server.ChunkedOutput.write( ~[jaxrs-ri-2.13.jar:2.13.] at com.appserver.webservice.AgentSsePollingManager$ ~[AgentSsePollingManager$ConnectionChecker.class:na] at java.util.concurrent.Executors$ [na:1.7.0_71] at java.util.concurrent.FutureTask.runAndReset( [na:1.7.0_71] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301( [na:1.7.0_71] at java.util.concurrent.ScheduledThreadPoolExecutor$ [na:1.7.0_71] at java.util.concurrent.ThreadPoolExecutor.runWorker( [na:1.7.0_71] at java.util.concurrent.ThreadPoolExecutor$ [na:1.7.0_71] at [na:1.7.0_71] Caused by: Broken pipe at Method) ~[na:1.7.0_71] at ~[na:1.7.0_71] at ~[na:1.7.0_71] at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes( ~[tomcat-coyote.jar:7.0.53] at org.apache.tomcat.util.buf.ByteChunk.flushBuffer( ~[tomcat-coyote.jar:7.0.53] at org.apache.coyote.http11.InternalOutputBuffer.flush( ~[tomcat-coyote.jar:7.0.53] at org.apache.coyote.http11.AbstractHttp11Processor.action( ~[tomcat-coyote.jar:7.0.53] at org.apache.coyote.Response.action( ~[tomcat-coyote.jar:7.0.53] at org.apache.catalina.connector.OutputBuffer.doFlush( ~[catalina.jar:7.0.53] ... 19 common frames omitted {code} JIRA | 2 years ago | ricb

  1. davidvanlaatum 4 times, last 3 months ago
  2. tfr 14 times, last 3 months ago
  3. kid 11 times, last 3 months ago
  4. dafman 1 times, last 2 weeks ago
  5. davidvanlaatum 2 times, last 1 month ago
18 more registered users
75 unregistered visitors
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis


    Broken pipe

  2. Java RT
    1. Method)
    4 frames
  3. Jetty
    1 frame