UI gets stuck intermittently with push enabled.

We are using Streaming Push in our application. Some times(randomly) the UI gets stuck with the spinner moving continuously.

The UI still works in the background. i.e notifications from the server are handled but the spinner never goes away once in this state. The only way to resolve this is to refresh the page.

I think somewhere in Vaadin when the UI is blocked with the loading indicator, it is never unblocked on the exception.

We should always unblock the UI and should just show the error when this happens.

i do see com.vaadin.client.ApplicationConnection.doUidlRequest(String, JSONObject) in case of exception, the request is ending(and UI unblocked) but looks like in some cases this never happens.

Here is the stacktrace. Hopefully someone here can make sense of this.

Jul 31, 2014 6:26:26 PM com.vaadin.server.DefaultErrorHandler doDefault
SEVERE:
java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:413)
at org.apache.catalina.connector.CoyoteReader.read(CoyoteReader.java:101)
at com.vaadin.server.communication.ServerRpcHandler.getMessage(ServerRpcHandler.java:502)
at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:173)
at com.vaadin.server.communication.PushHandler$3.run(PushHandler.java:172)
at com.vaadin.server.communication.PushHandler.callWithUi(PushHandler.java:244)
at com.vaadin.server.communication.PushHandler.access$200(PushHandler.java:55)
at com.vaadin.server.communication.PushHandler$1.onRequest(PushHandler.java:75)
at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:174)
at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:95)
at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:66)
at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.doService(Tomcat7Servlet30SupportWithWebSocket.java:67)
at org.atmosphere.container.TomcatWebSocketUtil.doService(TomcatWebSocketUtil.java:98)
at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.service(Tomcat7Servlet30SupportWithWebSocket.java:62)
at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1802)
at com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:144)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1408)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:237)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

I have this problem also. Still exists at vaadin 7.3.3…

I recommend trying long polling instead. It has turned out to be very difficult to make streaming work reliably enough.

Is there some relevant error logging in the browser log or in the Vaadin debug window when this happens?

Sorry for the late update. I am engaged with your vaadin support.

The only error message i see is the stack trace. Somehow the endrequest never gets called in case of an IO exception which happens when you are trying to read in ServerRpcHandler.getMessage() method.

Its an intermitten problem, so cant provide a easy test case. I am planning to keep a break point in my dev environment and when this error occurs i might have more information.

I noticed that compression (from server) can cause similar issues , specially when UI is loading.

In order to limit the problem on our dev server I configured compression to text/css,text/html,text/xml,text/javascript,application/json only. NOTE no text/plain.

The request that causes the issue was the last get the UI did apon initialization. and depending on the servers configuration the request/response would not always be gziped , so sometimes it works sometimes it dit not.

Sample of the working request.

GET http://aims.adept.za.net:8080/netflowweb-web/admin/PUSH/?v-uiId=0&v-csrfToken=7b27f097-09dd-4b09-b06e-ca7f062ae332&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=streaming&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1415896988509

Request Headers:
Host: aims.adept.za.net:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/json; charset=UTF-8
Referer: http://aims.adept.za.net:8080/netflowweb-web/admin
Cookie: JSESSIONID=9e41354d9b461db75843dd2e4637; treeForm_tree-hi=treeForm:tree:configurations:server-config:networkConfig:networkListeners:http-listener-2
Connection: keep-alive

Response Headers:
HTTP/1.1 200 OK
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
Expires: -1
X-Atmosphere-tracking-id: eb48bdbb-ee42-4d97-b522-3638d7701a8b
Connection: close
Content-Type: text/plain;charset=UTF-8
Date: Thu, 13 Nov 2014 16:43:03 GMT
Transfer-Encoding: chunked

If the server accepts/responds with a gziped (text/plain) the UI is blocked with the loading indicator(sometimes the indicator is not displayed but UI client still hangs) and request above simply timeout.

No error is logged for that request when it times-out.

Anycase It might be worth looking at your server’s compression settings.

Hmm. found one exception near the time of this issue ( but during testing I expected multiple errors to be logged so this exception might be unrelated ).

[code]
[2014-11-13T19:14:14.150+0200]
 [glassfish 4.1]
 [SEVERE]
 [] [com.vaadin.server.communication.PushHandler]
 [tid: _ThreadID=235 _ThreadName=Atmosphere-Shared-AsyncOp-3]
 [timeMillis: 1415898854150]
 [levelValue: 1000]
 [[
  Session expired before push was disconnected. This should never happen
com.vaadin.server.SessionExpiredException
        at com.vaadin.server.VaadinService.getWrappedSession(VaadinService.java:858)
        at com.vaadin.server.VaadinService.getExistingSession(VaadinService.java:828)
        at com.vaadin.server.VaadinService.doFindOrCreateVaadinSession(VaadinService.java:684)
        at com.vaadin.server.VaadinService.findOrCreateVaadinSession(VaadinService.java:659)
        at com.vaadin.server.VaadinService.findVaadinSession(VaadinService.java:518)
        at com.vaadin.server.communication.PushHandler.disconnect(PushHandler.java:351)
        at com.vaadin.server.communication.PushHandler.onDisconnect(PushHandler.java:330)
        at org.atmosphere.cpr.AtmosphereResourceImpl.onDisconnect(AtmosphereResourceImpl.java:663)
        at org.atmosphere.cpr.AtmosphereResourceImpl.notifyListeners(AtmosphereResourceImpl.java:582)
        at org.atmosphere.cpr.AtmosphereResponse.handleException(AtmosphereResponse.java:871)
        at org.atmosphere.cpr.AtmosphereResponse.write(AtmosphereResponse.java:968)
        at org.atmosphere.cpr.AtmosphereResponse.write(AtmosphereResponse.java:934)
        at org.atmosphere.cpr.AtmosphereInterceptorWriter.writeReady(AtmosphereInterceptorWriter.java:89)
        at org.atmosphere.cpr.AtmosphereInterceptorWriter.invokeInterceptor(AtmosphereInterceptorWriter.java:78)
        at org.atmosphere.cpr.AtmosphereInterceptorWriter.write(AtmosphereInterceptorWriter.java:64)
        at org.atmosphere.cpr.AtmosphereInterceptorWriter.write(AtmosphereInterceptorWriter.java:59)
        at org.atmosphere.cpr.AtmosphereResponse$2.write(AtmosphereResponse.java:503)
        at org.atmosphere.handler.AbstractReflectorAtmosphereHandler.onStateChange(AbstractReflectorAtmosphereHandler.java:141)
        at com.vaadin.server.communication.PushHandler$1.onStateChange(PushHandler.java:63)
        at org.atmosphere.cpr.DefaultBroadcaster.invokeOnStateChange(DefaultBroadcaster.java:1018)
        at org.atmosphere.cpr.DefaultBroadcaster$WriteOperation.call(DefaultBroadcaster.java:1059)
        at org.atmosphere.cpr.DefaultBroadcaster.prepareInvokeOnStateChange(DefaultBroadcaster.java:1033)
        at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:879)
        at org.atmosphere.cpr.DefaultBroadcaster$3.run(DefaultBroadcaster.java:520)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
]]
[/code]

I have similar (I think) problem. My Vaadin version is 7.3.2 and the container is Tomcat 7.0.42. My stack trace:

gru 16, 2014 8:32:55 AM com.vaadin.server.DefaultErrorHandler doDefault SEVERE: java.io.IOException: Stream closed at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:413) at org.apache.catalina.connector.CoyoteReader.read(CoyoteReader.java:101) at com.vaadin.server.communication.ServerRpcHandler.getMessage(ServerRpcHandler.java:494) at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:165) at com.vaadin.server.communication.PushHandler$3.run(PushHandler.java:174) at com.vaadin.server.communication.PushHandler.callWithUi(PushHandler.java:253) at com.vaadin.server.communication.PushHandler.access$200(PushHandler.java:56) at com.vaadin.server.communication.PushHandler$1.onRequest(PushHandler.java:76) at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:174) at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:95) at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:66) at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.doService(Tomcat7Servlet30SupportWithWebSocket.java:67) at org.atmosphere.container.TomcatWebSocketUtil.doService(TomcatWebSocketUtil.java:98) at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.service(Tomcat7Servlet30SupportWithWebSocket.java:62) at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1802) at com.vaadin.server.communication.PushRequestHandler.handleRequest(PushRequestHandler.java:144) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1402) at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:305) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) 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:744) Do you have any solution of this problem?
Is there an issue reported related to this case maybe?

Hi all,

we experienced a similiar issue (Tomcat 7, Vaadin 7.3.2, Websocket Push) where the UI would intermittently get stuck, the spinner would appear and never disappear, eventually going red.

The UI would not recover.

Here is the Bug Ticket:

http://dev.vaadin.com/ticket/15330#ticket

We always see the Hang on the client associated with this exception:

java.net.SocketException: Error when closing push connection
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.write(UpgradeBioProcessor.java:61)
at org.apache.coyote.http11.upgrade.UpgradeOutbound.write(UpgradeOutbound.java:44)
at org.apache.catalina.websocket.WsOutbound.doWriteBytes(WsOutbound.java:477)
at org.apache.catalina.websocket.WsOutbound.doWriteText(WsOutbound.java:529)
at org.apache.catalina.websocket.WsOutbound.doFlush(WsOutbound.java:267)
at org.apache.catalina.websocket.WsOutbound.close(WsOutbound.java:349)
at org.atmosphere.container.version.TomcatWebSocket.close(TomcatWebSocket.java:84)
at org.atmosphere.cpr.AtmosphereResponse.close(AtmosphereResponse.java:836)
at org.atmosphere.cpr.AtmosphereResourceImpl.cancel(AtmosphereResourceImpl.java:720)
at org.atmosphere.cpr.AtmosphereResourceImpl.close(AtmosphereResourceImpl.java:785)
at com.vaadin.server.communication.AtmospherePushConnection.disconnect(AtmospherePushConnection.java:293)
at com.vaadin.server.communication.PushHandler.disconnect(PushHandler.java:430)
at com.vaadin.server.communication.PushHandler.access$000(PushHandler.java:56)
at com.vaadin.server.communication.PushHandler$1.onStateChange(PushHandler.java:65)
at org.atmosphere.cpr.AsynchronousProcessor.invokeAtmosphereHandler(AsynchronousProcessor.java:468)
at org.atmosphere.cpr.AsynchronousProcessor.completeLifecycle(AsynchronousProcessor.java:420)
at org.atmosphere.cpr.AsynchronousProcessor.timedout(AsynchronousProcessor.java:381)
at org.atmosphere.cpr.AsynchronousProcessor$AsynchronousProcessorHook.timedOut(AsynchronousProcessor.java:545)
at org.atmosphere.websocket.DefaultWebSocketProcessor.close(DefaultWebSocketProcessor.java:493)
at org.atmosphere.container.TomcatWebSocketHandler.onClose(TomcatWebSocketHandler.java:80)
at org.apache.catalina.websocket.StreamInbound.doOnClose(StreamInbound.java:226)
at org.apache.catalina.websocket.WsOutbound.writeTextMessage(WsOutbound.java:229)
at org.atmosphere.container.version.TomcatWebSocket.write(TomcatWebSocket.java:53)
at org.atmosphere.websocket.WebSocket.write(WebSocket.java:217)
at org.atmosphere.websocket.WebSocket.write(WebSocket.java:185)
at org.atmosphere.websocket.WebSocket.write(WebSocket.java:42)
at org.atmosphere.cpr.AtmosphereResponse$2.write(AtmosphereResponse.java:503)
at org.atmosphere.handler.AbstractReflectorAtmosphereHandler.onStateChange(AbstractReflectorAtmosphereHandler.java:141)
at com.vaadin.server.communication.PushHandler$1.onStateChange(PushHandler.java:63)
at org.atmosphere.cpr.DefaultBroadcaster.invokeOnStateChange(DefaultBroadcaster.java:1018)
at org.atmosphere.cpr.DefaultBroadcaster.prepareInvokeOnStateChange(DefaultBroadcaster.java:1038)
at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:879)
at org.atmosphere.cpr.DefaultBroadcaster$3.run(DefaultBroadcaster.java:520)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Here is the forum post we made with more details on the issue:
https://vaadin.com/forum#!/thread/8712377

We contacted Vaadin support, and they said the ticket is not something they are currently working on.

We also tried upgrading to Tomcat 8, but instead of the “Error when closing push connection” exception when it hangs, we get the following message instead:

2014-12-16 13:27:27,352 CST WARN  [null]
 -
AtmosphereResource 8b002411-9007-4364-823c-771871f8dadf is not suspended.
If cached messages exists, this may cause unexpected situation. Suspend firs

We initially thought this was exclusive to WEBSOCKET, but we have subsequently seen it with LONG_POLLING and STREAMING modes, pretty much anything using Push.

we moved from streaming to WEBSOCKET PUSH mode and the problem is less prevalent. I would say 90% of the time i see the UI recovering from the red busy state. Hope that helps

I will keep following to see if the issue crops up again.