--- title: Configuring Push For Your Environment order: 15 layout: page --- [[configuring-push-for-your-environment]] = Configuring push for your environment Server push and especially websockets are emerging technologies and not all servers and browsers handle them correctly (or even close to correctly). Here are gathered a few known issues and ways to work around them: *Rule of thumb: Use the latest version of your server and the latest Vaadin version. Vaadin 7.6 has a completely rewritten logic for dealing with buffering proxies and unreliabilities in the connection to the server.* [[portals]] Portals ~~~~~~~ Push is not supported in portals. See https://dev.vaadin.com/ticket/11493 for more information. [[streaming]] Streaming ~~~~~~~~~ *Avoid streaming and use long-polling instead*. Streaming and long-polling works similarly on top of normal HTTP requests but streaming uses the same HTTP response for multiple messages whereas long-polling only writes on message per HTTP response. Especially proxies can cause problems with streaming as they might deliver only part of the message and buffer the rest. [[tomcat-6-streaming]] Tomcat 6 + Streaming ~~~~~~~~~~~~~~~~~~~~ For Tomcat 6, falling back to streaming always results in an error message such as [source] .... Failed using comet support: org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to detect this is a Comet application because context.xml is missing or the Http11NioProtocol Connector is not enabled.If that's not the case, you can also remove META-INF/context.xml and WEB-INF/lib/atmosphere-compat-tomcat.jar Is the Nio or Apr Connector enabled?WARNING: Using org.atmosphere.container.BlockingIOCometSupport .... Atmosphere is expecting the Servlet to implement Tomcat's proprietary interface https://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/CometProcessor.html[CometProcessor]. (See https://github.com/Atmosphere/atmosphere/blob/atmosphere-project-1.0.14/modules/cpr/src/main/java/org/atmosphere/cpr/AtmosphereServlet.java[AtmosphereServlet]) Vaadin's default servlet does not implement this interface. When fallback to native Comet fails, Atmosphere uses `BlockingIOCometSupport`, which seems to work with some applications and not with others. If it does not work for your application, you may want to try Tomcat 7 with a Servlet 3.0 application. [[tomcat-7-streaming]] Tomcat 7 + Streaming ~~~~~~~~~~~~~~~~~~~~ For Tomcat 7, if your application is a Servlet 3.0 application, set the property `org.atmosphere.useWebSocketAndServlet3=true` and make sure your Servlet and your filters in Web.xml have `true` or the equivalent annotation. For Servlet < 3.0, see "Tomcat6 + Streaming" above. [[tomcat-7-websockets]] Tomcat 7 + Websockets ~~~~~~~~~~~~~~~~~~~~~ Tomcat 7 is unable to share the HTTP session between HTTP request and websockets request. Because of this a FakeHttpSession (a copy of the real session) is used for websockets. This has certain implications such as that it is impossible to invalidate the session from a websockets enabled application. Tomcat 8 does not have this problem. The Websockets implementation in the 7.0.2x series is rather immature, so all kinds of issues may occur. If you use Tomcat 7, upgrade to the latest version! *It is recommended to upgrade to the latest Tomcat 8 (requires Vaadin 7.2+) if you want to use websockets.* [[tomcat-8-websockets]] Tomcat 8 + Websockets ~~~~~~~~~~~~~~~~~~~~~ .... java.lang.ClassNotFoundException: org.eclipse.jetty.websocket.WebSocketFactory$Acceptor .... This implies you have Jetty deployed on the classpath somewhere. Atmosphere gets confused and tries to use its Websocket implementation instead of Tomcat's. One common reason for this is that you have accidentally deployed vaadin-client-compiler, which has Jetty as a dependency (needed by SuperDevMode for instance.) [[glassfish-234-streaming]] Glassfish 2/3/4 + Streaming ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Glassfish 2/3/4 requires the "comet" option to be enabled for streaming to work. For Glassfish 2, set `(Configurations -> HTTP service -> HTTP listeners -> http-listener-1 -> Add Property -> "cometSupport"="true")` or use `asadmin set server.http-service.http-listener.http-listener-1.property.cometSupport=true` For Glassfish 3/4, set `(Configurations -> server-config -> Network Config -> Protocols -> http-listener-1 -> HTTP -> Comet Support)` or use `asadmin set server-config.network-config.protocols.protocol.http-listener-1.http.comet-support-enabled="true"` [[glassfish-3-websockets]] Glassfish 3 + Websockets ~~~~~~~~~~~~~~~~~~~~~~~~ As a rule of thumb, don't do this. The Grizzly version shipped with Glassfish 3.1.2.2 contains a https://github.com/javaee/grizzly/issues/1289[fatal bug] which prevents Vaadin from working. Replace *glassfish/modules/grizzly-websockets.jar* with http://central.maven.org/maven2/com/sun/grizzly/grizzly-websockets/1.9.56/grizzly-websockets-1.9.56.jar to get websockets working (with Vaadin 7.3). *This version is actually also broken in many ways, so you may or may not get it to work. If you want websockets, you should upgrade to Glassfish 4.* Glassfish 3 requires the websockets option to be enabled for websockets to work `(Configurations -> server-config -> Network Config -> Protocols -> http-listener-1 -> HTTP -> Websockets Support)` or `asadmin set server-config.network-config.protocols.protocol.http-listener-1.http.websockets-support-enabled="true"`. [[glassfish-4-websockets]] Glassfish 4 + Websockets ~~~~~~~~~~~~~~~~~~~~~~~~ Glassfish 4 + websockets require Vaadin 7.2+. *If you are using Glassfish 4.0, upgrade to Glassfish 4.1 to avoid problems* [[wildfly-8-websockets]] Wildfly 8 + Websockets ~~~~~~~~~~~~~~~~~~~~~~ Wildfly requires all websocket endpoints to be deployed during web application initialization and refuses to deploy them later. If you are using multiple push enabled Vaadin servlets you should mark them as load-on-startup=true to avoid issues. (Vaadin 7.2-7.4). Vaadin 7.5 fixes this by initializing websockets during context deployment so load-on-startup is not needed. [[weblogic-12-websockets]] Weblogic 12 + Websockets ~~~~~~~~~~~~~~~~~~~~~~~~ Use WebLogic 12.1.3 or newer with Java 8 and Vaadin 7.5+. If you see "java.lang.IllegalStateException: javax.websocket.server.ServerContainer is null. Make sure you are using 1.8+ and your server has websocket support enabled" you are probably running with Java 7 or older. WebLogic 12 specifies a timeout of 30s by default for websocket connections (https://docs.oracle.com/middleware/1212/wls/WLPRG/websockets.htm#WLPRG811). To avoid constant reconnects, you can set the init parameter `weblogic.websocket.tyrus.session-max-idle-timeout` to either -1 (no timeout in use) or a higher value than 30000 (value is in ms). [[jboss-eap-6.4-and-websockets]] JBoss EAP 6.4 and Websockets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ JBoss EAP 6.4 includes support for websockets but they are not enabled by default. To make websockets work you need to 1. Change JBoss to use the NIO connector + This can be done by running + `$ bin/jboss-cli.sh --connect` + and the following commands + .... batch /subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol) run-batch :reload .... 2. Add a *WEB-INF/jboss-web.xml* to you war file with the following contents to enable websockets [source,xml] ....

true

.... [[liberty-profileand-websockets]] Liberty profile and Websockets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use Liberty beta 2015.9.0.0 or later and Vaadin 7.6+. [[buffering-proxies-and-long-polling]] Buffering proxies and long polling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use Vaadin 7.6+ to deal with buffering proxies. Also see "Duplicate resource xyz-abc-def-ghi-jkl" below [[kaspersky-anti-virus-long-polling]] Kaspersky anti virus + long polling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use Vaadin 7.6+ to avoid problems with long polling. [[chrome-sayserr_incomplete_chunked_encoding]] Chrome says ERR_INCOMPLETE_CHUNKED_ENCODING ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is completely normal and means that the (long-polling) push connection was aborted by a third party. This typically happens when there is a proxy between the browser and the server and the proxy has a configured timeout and cuts the connection when the timeout is reached. The browser should reconnect to the server normally after this happens. Server logs contain .... Duplicate resource xyz-abc-def-ghi-jkl. Could be caused by a dead connection not detected by your server. Replacing the old one with the fresh one" .... This indicates that first, the browser connected to the server and used the given identifier for the push connection. Everything went as expected. Later on, a browser (probably the same one) connected again using the same identifier but according to the server, the old browser connection should still be active. The server closes the old connection and logs the warning. [[why-does-this-happen]] Why does this happen? ^^^^^^^^^^^^^^^^^^^^^ Typically there was a proxy between the browser and the server, and the proxy was configured to kill open connections after a certain inactivity timeout on the connection (no data is sent before the server issues a push command). Because of how TCP/IP works, the server has no idea that the connection has been killed and continues to think that the old client is connected and all is well. [[what-can-you-do-to-avoid-this]] What can you do to avoid this? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You have a couple of options: 1. If you are in control of the proxy, configure it not to timeout/kill push connections (connections to the /PUSH url) 2. If you know what the proxy timeout is, configure a slightly shorter timeout for push in the Vaadin application so that the server terminates the idle connection and is aware of the termination before the proxy can kill the connection. Use the `pushLongPollingSuspendTimeout` servlet parameter for this (defined in milliseconds) (Vaadin 7.6+) If you do not configure the proxy so that the server knows when the connection is killed, you also have a small chance of losing pushed data. If it so happens that the server does a push right after the connection was killed, it will not realize that it pushed data into a closed connection (because of how sockets work and especially how they work in Java). Disabling the timeout or setting the timeout on the server also resolves this potential issue.