Tag: push

Getting rid of Jetty related exceptions when using Vaadin Push with Tomcat

At least in Vaadin 7.3.x and 7.4.x, running on Tomcat with Push enabled, you may see several exceptions in your console having to do with Jetty. Even though you’re not using Jetty, this is happening because Vaadin is getting tricked into assuming that Jetty is being used, since a Jetty library is found in the Java classpath.

Vaadin does realize after the exceptions that Jetty isn’t actually there and continues gracefully. But though these exceptions are harmless, they’re still unsettling to constantly in your tomcat logs. As I mentioned, this is happening because there is some Jetty library in your Java classpath. So thus the obvious solution get to rid of these exceptions is to remove all Jetty libraries from your Java classpath. Search for any .jar’s that have “jetty” in the name, and remove them.

If you’re using Ivy or Maven dependency management, the library may be downloaded as a sub-dependency from another dependency. You will need to go through all your dependencies to check which ones also reference Jetty. The culprits in our case were vaadin-client-compiler and HtmlUnit (both reference Jetty for Jetty related things, but since we’re not using Jetty anyway, getting rid of the Jetty library should cause no harm).

We use Ivy, and I found how to exclude certain sub-dependencies, which is simple. Use the  tag in your ivy.xml wherever jetty is a sub-dependency. A example follows:

<exclude org="org.eclipse.jetty" name="*" />

And viola! No more random Jetty based exceptions from Vaadin.

Resolving Vaadin push with long polling issues in AWS Elastic Beanstalk

This took me a long time to figure out, so I thought I’d share it with anyone else struggling with this.

When you upload a Vaadin application to the AWS Elastic Beanstalk, Tomcat sits behind an Apache server that proxies connections to it. (Note: this may apply to you even if you’re not in AWS/ElasticBeanstalk. If you use Apache as a proxy to an application server, be it Tomcat or something else, this could still be an issue).

If you’re using Vaadin push in long polling mode (Transport.LONG_POLLING), it turns out that the connection between the client (browser) and server (tomcat, or your other java application server) gets dropped due to a timeout issue. If there is no data exchanged between the server (tomcat) and the client (browser), then the connection is deemed “idle” by Apache and gets dropped. This is an issue because with long polling, the HTTP connection remains open indefinitely, and that’s information is pushed to the client from the server.

Now with Vaadin’s push, it’s supposed to recover from a dropped connection. The connection is supposed to just get reestablished, and everything resumes. That’s an ideal scenario. In my experience, that doesn’t always work the way it should. If I’m on a Vaadin web app through my browser, and sit idle for a while, when I come back to it a lot of time it resumes fine (I can see push reestablishing itself in the console), but a lot of times the app just hangs forever.

Another thing to note is that Vaadin sends a heartbeat to the client, to check if the client is still there. The default heartbeat is every 5 minutes. When a heartbeat is sent, Apache’s idle connection timeout is reset. So if there is no user activity for a few minutes, the goal is to adjust the configuration so that the heartbeat happens before Apache times out the HTTP connection.

So the solution for this is to

  1. Modify Apache’s timeout for idle connections. I believe the default setting in AWS’s configuration for Apache, is 60 seconds. You’ll need to ssh into your server, edit /etc/httpd/conf/httpd.conf, and look for the “Timeout” directive. Change the Timeout directive to be greater-than the default Vaadin heartbeat of 5 minutes. Try 6 minutes (note: the Timeout value is in seconds), so you’d set “Timeout 360”. The downside of this approach is if your server has hundreds of thousands of requests, surely some legitimately idle connections (where the client is gone without cleaning up and not coming back) will linger for longer than 60 seconds, this affecting your system performance.
  2. Modify Vaadin’s heartbeat to be less than 60 seconds. You can edit your web.xml, and add an heartbeatInterval parameter like so: 
        <context-param>
        <param-name>heartbeatIntervalparam-name>
        <param-value>120param-value>
    context-param>
  3. You can tweak both the Vaadin heartbeat, and the Apache Timeout value to some reasonable values that suit your needs the best. Just make sure that the heartbeat interval is shorter than the timeout.

Enjoy!