2015-05-06 9 views
0

Я использую различные версии Cometd Java API в течение нескольких лет (в настоящее время v2.5.1), и все работает так, как ожидалось. Однако мои журналы заполняются множеством исключений, в основном java.io.IOException и org.eclipse.jetty.io.EofException.Работа с исключениями Cometd

я наткнулся this forum post, где он объяснил, что по крайней мере один из исключений, а именно «Broken труба» может быть просто проигнорированы:

Это исключение вызвано запись в сокет, который был закрыт удаленный конец. Ваш клиент решил резко закрыть сокет. Если это настоящий журнал (в отличие от тестового журнала), клиент мог бы закрыть браузер, поставить компьютер в сон и т. Д.

Просто проигнорируйте его.

Теперь у меня есть еще пару исключений, которые были заполняющих мой журнал в течение многих лет, для получения более подробной трассировки стека см ниже фактического вопроса:

  • java.io.IOException: closedOut 1006:null
  • java.io.IOException: closedOut 1006:null
  • org.eclipse.jetty.io.EofException: Closed
  • java.io.IOException: Connection reset by peer

Таким образом, мой вопрос: безопасно ли игнорировать эти Исключения, или есть что-то, я могу изменить код (кроме изменения loglevel), чтобы быть в безопасности?

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] 
+1

[Jetty 8 is End-of-Life now] (https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00069.html). Рассмотрите возможность обновления до Jetty 9. –

+2

Кроме того, CometD 2.x устарел, рассмотрим обновление до CometD 3. – sbordet

+0

Оба обновления запланированы в ближайшем будущем. Ура! – msparer

ответ

2

CometD сервер не по умолчанию, тесные связи, если они не простаивают в течение длительного времени. Однако, поскольку CometD имеет встроенный механизм сердечных сокращений, соединения никогда не будут оставаться достаточно простыми, чтобы вызвать закрытие на стороне сервера (при условии, что сеть стабильная).

Каждый раз, когда вы сталкиваетесь с ситуацией, когда сервер не может писать клиенту, потому что соединение закрыто, обычно это связано с закрытием клиента или сбоем в сети между клиентом и сервером.

Этот вид исключений можно игнорировать в журналах на стороне сервера. Все исключения, о которых вы сообщали в своем вопросе, имеют такой вид.

Рассмотрите возможность модернизации до CometD 3.x.