2014-05-13 14 views
5

Próbuję skonfigurować klienta/serwer websocket. Problem powstaje w wyniku aktywności w sesja, w której po około 30 ~ 60. bez przekazywania danych klient zamyka połączenie, z wyjątkiem:Limit czasu oczekiwania na webtyty Jetty

org.eclipse.jetty.websocket.api.WebSocketTimeoutException: Timeout on Read 
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onReadTimeout(AbstractWebSocketConnection.java:505) 
at org.eclipse.jetty.io.AbstractConnection.onFillInterestedFailed(AbstractConnection.java:258) 
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillInterestedFailed(AbstractWebSocketConnection.java:481) 
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.failed(AbstractConnection.java:415) 
at org.eclipse.jetty.io.FillInterest.onFail(FillInterest.java:100) 
at org.eclipse.jetty.io.AbstractEndPoint.onIdleExpired(AbstractEndPoint.java:146) 
at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:153) 
at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 
at java.util.concurrent.FutureTask.run(FutureTask.java:166) 
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) 
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:722) 

ES: gniazdo Zamknięte: [1001] Limit bezczynności

To nie ma sensu, ponieważ próbowałem zarówno po stronie klienta i po stronie serwera, aby ustawić maxIdleTimeout do znacznie większych wartości, a nawet po sesji ustalono, sprawdzam go:

client.setMaxIdleTimeout(0); 

i próbowałem różnych wartości zamiast "0" powyżej bez skutku.

Odpowiedz

2

Ten numer ma 2 lata, ale nadal istnieje. Powodem tego jest domyślny limit czasu Jetty websocket jest 5 minut (patrz org.eclipse.jetty.websocket.api.WebSocketPolicy), natomiast na Tomcat jest 0.

Aby go naprawić, w kodzie klienta websocket można zrobić coś wzdłuż tych linii:

WebSocketContainer container = ContainerProvider.getWebSocketContainer(); 
Session session = container.connectToServer(this, endpointURI); 
session.setMaxIdleTimeout(0); 
  • testowane przy użyciu Jetty 9.3.9.v20160517 i Tomcat 8+ - problem przestał pojawiać się na pomoście, a Tomcat zachowuje się tak samo.

Jednak może być dobrym pomysłem wdrożenie @OnError i wykonanie session.close() i ponowne połączenie w celu utrzymania stabilności połączenia. Ponadto, Jetty's WebSocketTimeoutException pochodzi od RuntimeException, możesz sprawdzić instancję Throwable i ponownie połączyć tylko na RuntimeExceptions. A "prawdziwe" przetwarzanie błędów w sytuacjach takich jak serwer jest wyłączone itp. Powinno być w przetwarzaniu IOException z container.connectToServer()