Question

I’m working on a Java SE 7 / Java EE 6 application that may use either Tomcat 7 or Glassfish 3.1 (probably GlassFish, but this has not been decided yet). The application will take advantage of the new WebSockets technology that has recently achieved widespread adoption across all major browsers.

Through much research, forum reading and mailing list monitoring I have determined that (currently, AFAICT) neither mod_jk/isapi_redirect nor mod_proxy reliably (or at all) support WebSockets. Since these are the two tried and tested methods for load balancing/directing traffic in a Tomcat or GlassFish cluster, this obviously represents a problem.

On the other hand, however, Tomcat and GlassFish both have built-in web servers that are widely touted to be just as efficient at serving static content as Apache or IIS, and therefore it is generally not recommended to place Apache or IIS in front of one of these servers UNLESS you need redundancy/load balancing.

So, all of this leads me to these questions:

1. Is Apache or IIS even needed anymore to load balance in a Tomcat/GlassFish cluster? Wouldn’t it be just as efficient (or more so?) to simply place a standard load balancer, like what you would use in any other scenario, in front of a cluster of Tomcat or GlassFish servers and forego the intermediary web server altogether? Or is there still some technical reason that standard load balancers won’t work with TC/GF? Assuming a standard load balancer could be used, one could simply find one that supports WebSockets (like Coyote) and use it.
2. If a standard load balancer will simply not work with Tomcat/GlassFish, what other options are there? How can one effect performant and reliable WebSocket technology using Java EE?

Caveat: I prefer not to consider load-balancing technologies that are limited to dumb round-robin protocols (such as Round-Robin DNS). I do not consider these options reliable/redundant, as one could easily be sent to a server that was down or already handling a much larger number of connections than another server in the cluster. Obviously I know that something like Round-Robin DNS could easily be used with WebSockets without any compatibility concerns.

Answer 1

We were going to use an approach with having our Tomcat instances directly after a standard load balancer. We use SSL heavily in our setup. To keep things simple behind our load balancers and avoid different configurations for SSL/no SSL in our web container we wanted to terminate SSL in our load balancers.

However, the SSL decrypting hardware for our load balancers was quite buggy. Hence we ended up with web servers (nginx) between our web containers and our load balancers for the sole purpose of decrypting SSL.

This is a special case that applied to us but is worth keeping in mind. Apart from this I do not see a reason to keep a web server between your load balancer and your web container. The load balancer should work just fine with the web container. Aim for simplicity and minimzing the different components in your setup.