Vaadin 7 Push stability issues

I have been using Vaadin 7.3.0 and 7.3.1 with Push enabled in various configurations (manual, automatic, websockets, streaming, long polling) on Tomcat 7.0.53 and Tomcat 8.0.12 with Apache 2.2 reverse proxy. There is only one place in my application where I am actually using push but it seems to be all or nothing when it comes to push. When I was doing the development with Tomcat 7.0.47 in Eclipse it seemed to work fine. But when I deployed it to a test system with production environment servers it seems to hang for long periods particularly in Firefox 32 and Chrome 37. In IE 11 it seemed to work fairly well, only hanging occasionally. The same results occured when I bypassed the Apache reverse proxy.

In the web console in Firefox I saw a few push related errors consistently but they are really internal to the push mechanism rather than anything I can affect:

syntax error @
/PUSH/?v-uiId=0&v-csrfToken=5c1833b5-c23b-49f0-a977-92c6cff6193f&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1411409623873:2

no element found @
/PUSH/?v-uiId=0&v-csrfToken=5c1833b5-c23b-49f0-a977-92c6cff6193f&X-Atmosphere-tracking-id=127b995e-75e2-43f1-b250-dba9d952d101&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=polling&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&_=1411409739463:1

I tried both HTTP/1.1 and org.apache.coyote.http11.Http11NioProtocol protocols in Tomcat but both seem to behave similiary.

When I turn Push off it works fine. I changed my application to only update the area I want to push to only when the button is clicked. While I would prefer that the window, when left open, updated with push, it seems far too unstable to use it.

There isn’t much I can provide in terms of troubleshooting information. When the browser hangs there is no logging activity. For instance, if I log into the application it hangs after entering the username/password and clicking login. The log shows it hanging for about a minute then it goes to the main page and the main page shows up. The push activity occurs every 6 seconds and I can see that in the log. But as I click through the application it just keeps hanging, sometimes it never recovers.

If I’m running through the Apache reverse proxy I see errors from that:

(70007)The timeout specified has expired: proxy: error reading response

(20014)Internal error: proxy: error reading status line from remote server localhost, referer:

(104)Connection reset by peer: proxy: error reading status line from remote server localhost, referer:

proxy: Error reading from remote server returned by /myapp/PUSH/, referer:

This is what I see the catalina log for atmosphere:

Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework addAtmosphereHandler
INFO: Installed AtmosphereHandler com.vaadin.server.communication.PushHandler$1 mapped to context-path: /*
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework addAtmosphereHandler
INFO: Installed the following AtmosphereInterceptor mapped to AtmosphereHandler com.vaadin.server.communication.PushHandler$1
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework doInitParams
WARNING: SessionSupport error. Make sure you define org.atmosphere.cpr.SessionSu
pport as a listener in web.xml instead
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework autoConfigureService
INFO: Atmosphere is using org.atmosphere.cpr.DefaultAnnotationProcessor for processing annotation
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.DefaultAnnotationProcessor configure
INFO: AnnotationProcessor class org.atmosphere.cpr.DefaultAnnotationProcessor$ServletContainerInitializerAnnotationProcessor being used
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.DefaultAnnotationProcessor fallbackToManualAnnotatedClasses
WARNING: Unable to detect annotations. Application may fail to deploy.
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework autoDetectWebSocketHandler
INFO: Auto detecting WebSocketHandler in /WEB-INF/classes/
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework initWebSocketINFO: Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework configureAtmosphereInterceptor
INFO: Installing Default AtmosphereInterceptor
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.CorsInterceptor : CORS Interceptor Support
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.CacheHeadersInterceptor : Default Response’s Headers Interceptor
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.PaddingAtmosphereInterceptor : Browser Padding Interceptor Support
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.AndroidAtmosphereInterceptor : Android Interceptor Support
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.HeartbeatInterceptor : Heartbeat InterceptorSupport
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.SSEAtmosphereInterceptor : SSE Interceptor Support
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.JSONPAtmosphereInterceptor : JSONP Interceptor Support
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.JavaScriptProtocol : Atmosphere JavaScript Protocol
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.WebSocketMessageSuspendInterceptor : org.atmosphere.interceptor.WebSocketMessageSuspendInterceptor
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.OnDisconnectInterceptor : Browser disconnection detection
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework newAInterceptor
INFO: org.atmosphere.interceptor.IdleResourceInterceptor : org.atmosphere.interceptor.IdleResourceInterceptor
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework configureAtmosphereInterceptor
INFO: Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults to disable them.
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Using EndpointMapper class org.atmosphere.util.DefaultEndpointMapper
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Using BroadcasterCache: org.atmosphere.cache.UUIDBroadcasterCache
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Default Broadcaster Class: org.atmosphere.cpr.DefaultBroadcaster
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Broadcaster Polling Wait Time 100
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Shared ExecutorService supported: true
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Messaging Thread Pool Size: Unlimited
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Async I/O Thread Pool Size: 200
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: HttpSession supported: true
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Atmosphere is using DefaultAtmosphereObjectFactory for dependency injection and object creation
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Atmosphere is using async support: org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket running under container: Apache Tomcat/7.0.53 using javax.servlet/3.0
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework info
INFO: Atmosphere Framework 2.1.2.vaadin5 started.
Sep 22, 2014 3:16:26 PM org.atmosphere.cpr.AtmosphereFramework interceptor
INFO: Installed AtmosphereInterceptor Track Message Size Interceptor using | with priority BEFORE_DEFAULT

I’m experiencing the exact same problem with version 7.3.1.

We also have the similar problems in production with push and websockets!! On tomcat 8.12, most recent Vaadin 7.3.3.
/PUSH/* context must be handled with proxy that supports websockets! Standard AJP connector mod_proxy_ajp cannot handle websockets. For proxying on apache webserver you must use “proxy_wstunnel_module”. It is available for apache 2.4.5+ version. So you need Centos7 or Debian Unstable for hosting. I am missing this in Vaadin documentation!!
http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html

this apache configuration can look like this:

ProxyPreserveHost On ProxyPass /PUSH/ ws://XXX:8080/PUSH/ retry=0 keepalive=On ProxyPassReverse /PUSH/ ws://XXX:8080/PUSH/ retry=0

ProxyPass / http://XXX:8080/ retry=0 keepalive=On
ProxyPassReverse / http://XXX:8080/ retry=0

This setup looks working, BUT it is not stable for production usage.

We have frequent RANDOM issues with "A filter or servlet of the current chain does not support asynchronous operations”.
If tomcat runs without apache proxy this error sometimes occurs with less frequency. In development enviroment (maven jetty plugin) we never saw this error. We also tried to use jetty 9.1 on production server, async errors are less frequent than on tomcat 8. Big problem is that vaadin application is stuck without raising some exception or error message, there is now chance how to handle this in browser.

We are using servlet 3.0 and have enabled true on servlet and all filters.
It is impossible debug which filter causes the problem…

BTW: We are using org.springframework.orm.hibernate4.support.OpenSessionInViewFilter.

Oct 31, 2014 3:38:08 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [eauction]
in context with path threw exception [com.vaadin.server.ServiceException: java.lang.IllegalStateException: A filter or servlet of the current chain
java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.
at org.apache.catalina.connector.Request.startAsync(Request.java:1594)
at org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1037)
at javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:384)
at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:678)
at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:93)
at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:68)
at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1802)

Is there any information to help people suffering from this? It’s troubling because for users who do get it because it seems to completely lock them up and keep them from moving forward, while others are able to work okay.

I reported this previously, too, under
https://vaadin.com/forum#!/thread/7902921
when we throught it might be related to Safari only, but it seems to occur on various browsers, but it’s not always easy to track as users have so many different setups when accessing over the Internet.

I am running Java 1.8.0_25, Tomcat 8.0.15, no Apache HTTPD front-end, SSL/HTTPS, Vaadin 7.3.6. We are currently using ‘automatic’ push with no transport setting, but we do have true in our UI’s servlet entry.

Is anybody successfully using PUSH across the Internet?

Is PUSH enabled on a per-UI basis likely to work? I’m wondering if I should just let the user turn push on/off from the UI and whether that would work or not.

The exception:

2014-12-07 10:03:46,917 ERROR (com.esignforms.open.vaadin.EsfVaadinUI) init().VaadinSession.ErrorHandler.error()
java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.
        at org.apache.catalina.connector.Request.startAsync(Request.java:1604)
        at org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1037)
        at javax.servlet.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:392)
        at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:678)
        at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:93)
        at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:68)
        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:1406)
        at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:305)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:613)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
        at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
        at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)

I noticed PUSH is more stable with Jetty than Tomcat. I don’t know why, but I hadn’t any serious issues with proxying PUSH via apache even with Websockets.

Crossed checked that exception with the Tomcat access log and so these are likely the requests being made (related requests were for regular non-PUSH resources that all show a status 200 being returned.

This shows the errors occurred with an IE9 browser and appears to use long-polling right from the start at login:

xx.xx.148.130 - - [07/Dec/2014:10:03:46 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975426827 HTTP/1.1" 200 2120 29 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:46 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975426869 HTTP/1.1" 200 229 59 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:46 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975426940 HTTP/1.1" 200 440 2 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:47 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975426966 HTTP/1.1" 200 439 16 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:47 -0800]
 "GET /WebApp/VAADIN/themes/reindeer/notification/img/error-close.png HTTP/1.1" 200 653 2 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:47 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975426995 HTTP/1.1" 200 229 2 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:47 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975427065 HTTP/1.1" 200 439 6 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:47 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975427090 HTTP/1.1" 200 64 5 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432145 HTTP/1.1" 200 440 7 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432173 HTTP/1.1" 200 228 2 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432219 HTTP/1.1" 200 438 8 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432244 HTTP/1.1" 200 439 6 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432274 HTTP/1.1" 200 439 6 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432300 HTTP/1.1" 200 439 6 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:52 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975432365 HTTP/1.1" 200 78 23 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:57 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&X-Atmosphere-Framework=2.1.5.vaadin4-jquery&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application%2Fjson%3B%20charset%3DUTF-8&X-atmo-protocol=true&_=1417975437464 HTTP/1.1" 200 440 15 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
xx.xx.148.130 - - [07/Dec/2014:10:03:59 -0800]
 "GET /WebApp/ui/PUSH/?v-uiId=0&v-csrfToken=c07cec89-f178-41fa-823e-035f28cba067&X-Atmosphere-Transport=close&X-Atmosphere-tracking-id=d00ed9b7-968c-41ed-98a8-050b523e3049&_=1417975425161 HTTP/1.1" 200 - 1 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Considering our first attempt to fix this would be to switch to long-polling, I don’t see that helping as it was already using long-polling. I figured long-polling would be reliable as it sounds like it’s really not doing anything special other than holding a second connection open to periodically request updates.

Which transport is most likely going to work: websocket, streaming or long-polling?

Curious as to the approaches anybody uses for their successful use of PUSH over the Internet… Like, can I use browser versions to turn it off for those less likely to work? Allow the user to turn it on/off for their session?

After very frustrating elaboration, upgrade from Tomcat 8.0.12 to Tomcat 8.0.15 and switch to long-polling transport fixed all async errors.

That’s nice it’s working for you. We’re also using TC 8.0.15l, but still see issues, including errors on long-polling transports. It’s not clear, but we suspect perhaps it’s older browsers that are having issues, but it could be related to the network the user is on (by older, we mean anything older than IE 10, Opera 11, Safari 5, Chrome 13 and Firefox 9. We definitely have seen issues on IE8 and IE9, but again, it’s hard to know what is causing the exceptions as a fix that appears to work turns out not to really solve it as we continue in production use across the Internet (we never saw any such issues during our local testing).

While not perfect, excluding older browsers does get rid of that exception that blocks UI access going forward.

That exception does not include any of our code, so it must be a bug of some sort in the Vaadin framework (or in the setup documentation?) with respect to PUSH:

java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations.

That exception breaks the UI for all users who experience it, and it occurs without ever entering any of our code (per the stack trace). If there’s something we can tweak to fix it, we’d be happy to try.

So, while users on older browsers won’t get the best experience (no push), that will help motivate them to be more secure and sensible and stop using old browsers. We basically added this code to our UI.init(VaadinRequest vaadinRequest) overridden method:

        // Hack to turn off PUSH on older web browsers...
        if ( isTooOldForPush() ) {
            _logger.warn("init() - Disabling PUSH for UI because isTooOldForPush()...");
            getPushConfiguration().setPushMode(PushMode.DISABLED);
        }

And here’s the isTooOldForPush() which we based on some Atmosphere documentation that I’m not sure applies to the Vaadin integration or not! But the result is we see browsers getting push turned off, and we’re no longer seeing that exception that kills the user’s UI.

    boolean isTooOldForPush() {
        WebBrowser wb = Page.getCurrent().getWebBrowser();

        if ( wb.isIE() && wb.getBrowserMajorVersion() < 10 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: IE < 10: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
          }
        if ( wb.isSafari() && wb.getBrowserMajorVersion() < 5 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Safari < 5: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isFirefox() && wb.getBrowserMajorVersion() < 9 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Firefox < 9: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isOpera() && wb.getBrowserMajorVersion() < 11 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Opera < 11: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isChrome() && wb.getBrowserMajorVersion() < 13 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Chrome < 13: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }

        return false;
    }

Of course the above code could be streamlined without

By the way, we found the above isTooOld to not be quite right, though it’s very odd we have to configure automatic push over the Internet on a browser version basis rather than push doing this itself as it should know what works using its code better than we do by testing versions!

If Safari is < 6 (not 5), push should be turned off.
If Firefox is < 17 (not 9), push should be turned off.
If Chrome is < 23 (not 13), push should be turned off.
If Opera is < 12 (not 11), push should be turned off.

Note that most of these oldest versions have not been tested, but just haven’t shown up to cause PUSH crashes that eventually cause major Tomcat web server outages (consumes all resources, which I’m guessing is either file descriptors or threads) on Linux (CentOS 6) that requires a server reboot to resolve!

    boolean isTooOldForPush() {
        WebBrowser wb = Page.getCurrent().getWebBrowser();
        if ( wb.isIE() && wb.getBrowserMajorVersion() < 10 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: IE < 10: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
          }
        if ( wb.isSafari() && wb.getBrowserMajorVersion() < 6 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Safari < 6: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isFirefox() && wb.getBrowserMajorVersion() < 17 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Firefox < 17: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isOpera() && wb.getBrowserMajorVersion() < 12 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Opera < 12: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        if ( wb.isChrome() && wb.getBrowserMajorVersion() < 23 ) {
            _logger.warn("isTooOldForPush() - TOO OLD: Chrome < 23: browserApp: " + wb.getBrowserApplication() + "; major:" + wb.getBrowserMajorVersion() + "; minor: " + wb.getBrowserMinorVersion());
            return true;
        }
        return false;
    }

I upgraded to 7.3.7, push seems to work across all reasonably supported browser staring with IE8-IE11, firefox, safari (ipad), deault android browser starting with for 4.1 (tested). Solution we have has also spring security in it. Little bit work to make it work, but it seems to be ver stable now.
Down side: 3 time more requests (due to athmosphere trafic). but You can use extensivly multithreading.

In order to understand how push works I would sugest you to add and register (in web xml) atmospere interceptor:
something what implements AtmosphereInterceptor, each request would be processed with it.
Hint:
use this code inside to get access to the sesson:

vaadinSessionObj = atmosphereResource.getRequest()
.getAttribute(“com.vaadin.server.VaadinSession”);

and
atmosphereResource.transport() to see which type of transport protocol is in place:
dependedn on a browser it can be websocket or pooling/long pooling combination.

Push works in 3.7. Heart beat works as well as far I can see, session expiration works.

Did you deploy on Tomcat? Where there any tomcat config considerations to make it work for you better? OS considerations for Linux? We run multiple webapps (all Vaadin) on a single Tomcat instance and found it would crash the server by exhausting all resources. Monitoring has not made it clear what is going wrong as the server doesn’t seem to have issues until it can no longer do anything. I’d guess we’re running out of file descriptors or threads. Logged in terminals cannot do any additional commands as they all return with the insufficient resource errors.

It may run for 2-3 days and then crap out. And often enough we’ll just get a spinning cursor and the UI never becomes responsive again, but if you refresh the page then it’s okay again. We are not even using push directly yet, just turning it on to see if it can be reliable for us before we architect in the feature.

As it is now, we have disabled push and then all of the problems go away.

We are having similar issues… Unfortunately, due to the nature of the issue we didn’t uncover them until we released a live (beta) system :-(.

We were originally running Tomcat 7.0.52 with Vaadin 7.3.1 with push (websockets) enabled on Linux. We do make use of push in our application. The issue we had was that connecting with an unsupported browser (basically IE below version 10) killed the server. Attempting to access the login page after an unsupported browser had connected resulted in a blank page. Repeatedly trying to access the login page with Chrome worked after several attempts but the system was unstable.

We found a
Vaadin wiki page
that stated Tomcat 7 doesn’t support websockets and so we investigated deploying into Tomcat 8.0.15 which appeared to solve the issue (as per our testing). However, users are still reporting issues connecting, and our tomcat logs now show the same error as yours David although it appears intermittent. Maybe it is linked to users connecting with unsupported browsers although we tested with IE8 and although requests take significantly longer, they eventually succeed.

As far as I can tell this is a Vaadin/Atmosphere issue - it would be useful to have some insight from a Vaadin engineer. Our only option bar refactoring to remove push from the application appears to be to configure Vaadin to use long-polling rather than websockets although it seems as this is not a guaranteed fix.

Any suggestions would be welcome.

This thread seems to have come to a halt 10 months ago.

We have:

  • Vaadin 7.5.8
  • Tomcat 8.0.26
  • JDK 8

When connecting directly to Tomcat server all is well.

However, when proxying through an apache 2 webserver things hang. We looked at the entry by Robert Hajek (above - very helpful). He had some settings for Apache2.

Finally, the following worked for me:

ProxyPass /poc/app/PUSH ws://localhost:8080/poc/app/PUSH/ retry=0 keepalive=On ProxyPassReverse /poc/app/PUSH ws://localhost:8080/poc/app/PUSH/ retry=0 ProxyPass /poc ajp://localhost:8009/poc ProxyPassReverse /poc ajp://localhost:8009/poc As Robert mentioned, this requires the mod_proxy_wstunnel module to be loaded in Apache2.

  • Q: Should every Servlet [VaadinServlet subclasses and all other Servlets in the application]
    be marked as asyncSupported=true?
  • Q: Should every Filter be marked as asyncSupported=true?
  • Q: Does Vaadin consider Server Push with Vaadin on Tomcat to be a mature/stable technology?
  • Q: Does Vaadin recommend (or prefer) one type of Transport over another? (WEBSOCKET, LONG_POLLING, STREAMING?)

We have exactly the same configuration, but still won’t work for us! Could you PLEASE post server.xml connector properties from Tomcat (with all connectors) or you maybe know what could be some another related problem?

Thank you very much in advance!

P.S. It’s virtual host on apache running on Ubuntu.

Hello Nemanja,

Here are the connectors from Tomcat’s server.xml:

 <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
   <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               keystoreFile="/path_to/tomcat.keystore"
               keystorePass="****"
               clientAuth="false" sslProtocol="TLS" />
 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

Ok, thanks a lot!
We will try to replace our connectors with yours and see if that is a solution.

Hi, So I have a similar problem, I am using Vaadin 7.6.4, Tomcat 8.5.28, Java 8, Servlet 3.1.0

My configuration:


Servlet:

@WebServlet(
asyncSupported = true, urlPatterns = {“/", "/VAADIN/”},
initParams = { @WebInitParam(name = “beanName”, value = “portalUIImpl”),
@WebInitParam(name = “pushmode”, value = “automatic”)
}
)

I already set “@PushMode(MANUAL)” in my View.

Now, I’m using “@PushMode(MANUAL)” only in one View. But also I have other Views without “@PushMode()”.

It works PERFECT on my local machine, but in “production environment” is showing the ERROR in the file attached:

  • Please, how I can fix this Issue?, or You believe that I am ignoring some configuration?

41303.png

What’s this apparent

<async-supported>true</async-supported>

config parameter you are talking about?

I hope it’s a typo, because all I have in my project, both when I was putting it using @WebServlet annotation I had a

asyncSupported = true

parameter, and now that I’m using web.xml, I have this equivalent init-param:

<init-param>
            <param-name>asyncSupported</param-name>
            <param-value>true</param-value>
</init-param>

I came here because I’m experiencing similar problemas and I found this thread after some googling. Is it possible that I used the wrong configuration when switching to web.xml-based configuration??

Ok, so it seems it was my fault.

I re-read the docs here and assured I’m using the proper configuration:

https://vaadin.com/docs/v7/framework/advanced/advanced-push.html

Doing that implied removed my wrong asyncSupported init-param.

No exceptions for the moment.