I've been using various versions of the Cometd Java API for some years (currently v2.5.1) and everything works as expected. However my logs get filled with a lot of exceptions, mostly java.io.IOException and org.eclipse.jetty.io.EofException.
I came across this forum post where it's explained that at least one of the Exceptions, namely the "Broken pipe" can just be ignored:
This exception is caused by writing to a socket that's been closed by the remote end. Your client decided to abruptly close the socket. If this is a real log (as opposed to a test log), the client could have closed the browser, put the computer in sleep, etc.
Just ignore it.
Now, I have a couple of more exceptions that have been filling my log for years, for more detailed stack traces see below the actual question:
java.io.IOException: closedOut 1006:nulljava.io.IOException: closedOut 1006:nullorg.eclipse.jetty.io.EofException: Closedjava.io.IOException: Connection reset by peerMy question therefore is: is it safe to ignore these Exceptions too, or is there something, I can change codewise (other than changing the loglevel) to be safe?
Stacktraces:
12:36:28 WARN - .s.s.l.BayeuxInitializer$1 - (pool-1-thread-20)
java.io.IOException: closedOut 1006:null
at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455$WSFrameConnection.sendMessage(WebSocketConnectionRFC6455.java:447) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:244) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:238) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.schedule(WebSocketTransport.java:555) [cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.run(WebSocketTransport.java:469) [cometd-websocket-jetty-2.5.1.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
12:38:54 WARN - .s.s.l.BayeuxInitializer$1 - (pool-1-thread-27)
org.eclipse.jetty.io.EofException: Closed
at org.eclipse.jetty.websocket.WebSocketGeneratorRFC6455.addFrame(WebSocketGeneratorRFC6455.java:80) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455$WSFrameConnection.sendMessage(WebSocketConnectionRFC6455.java:449) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:244) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:238) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.schedule(WebSocketTransport.java:555) [cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.run(WebSocketTransport.java:469) [cometd-websocket-jetty-2.5.1.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
12:33:46 WARN - .s.s.l.BayeuxInitializer$1 - (pool-1-thread-45)
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.7.0_65]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) ~[na:1.7.0_65]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) ~[na:1.7.0_65]
at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.7.0_65]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) ~[na:1.7.0_65]
at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:288) ~[jetty-io-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:356) ~[jetty-io-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.eclipse.jetty.websocket.WebSocketGeneratorRFC6455.flushBuffer(WebSocketGeneratorRFC6455.java:207) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.eclipse.jetty.websocket.WebSocketGeneratorRFC6455.addFrame(WebSocketGeneratorRFC6455.java:174) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455$WSFrameConnection.sendMessage(WebSocketConnectionRFC6455.java:449) ~[jetty-websocket-8.1.5.v20120716.jar:8.1.5.v20120716]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:244) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport.send(WebSocketTransport.java:238) ~[cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.schedule(WebSocketTransport.java:555) [cometd-websocket-jetty-2.5.1.jar:na]
at org.cometd.websocket.server.WebSocketTransport$WebSocketScheduler.run(WebSocketTransport.java:469) [cometd-websocket-jetty-2.5.1.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_65]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]
The CometD server does not, by default, close connections, unless these are idle for a long time. However, since CometD has a built-in heartbeat mechanism, the connections will never remain idle enough to trigger a server-side close (assuming the network is stable).
Every time you encounter a situation where the server cannot write to the client because the connection is closed, this is typically due to the client closing the connection or to a faulty network connectivity between client and server.
This type of exceptions can be ignored on server side logs. All the exceptions you reported in your question are of this kind.
Consider upgrading to CometD 3.x.