Wish List: Session Moratorium

DetourA feature that the major open-source/free servlet containers (Tomcat, Jetty, Resin) lack, AFAIK, is the ability to tell the container to stop issuing new sessions, and more importantly, make this flag known to the HTTP server connector. One or more of Websphere, Weblogic, and ATG Dynamo (I forget which) has this ability, and it’s extremely useful for higher-volume websites.

How it works: Server Bank A is running, Server Bank B is dormant. When you have a new release, you push it to B. Once B is up and running (this can take a while with some advanced applications), you tell A to stop issuing new sessions, and the load balancers send all new traffic to B. Once traffic has bled off of A entirely, A becomes dormant, and is ready for the next release.

Why it’s valuable: You can do a release without interrupting any sessions. This was particularly valuable on the project we used it on, because there was plenty of time to pre-compile pages, and the transactions were relatively high-value ones, so it was worth the price of the commercial license to ensure that none were lost or interrupted.

Considering all of the containers are relatively close performance-wise, and feature-wise, I think this would be a “killer feature” for any OSS container that had it.

  • Why do this at the servlet container level instead of the load balancer level? If you have a load balancer that supports sticky sessions, you take server bank A “off the balancer” when server bank B is ready, and no more new sessions would be created on A, only B.

    Given that most of the high-volume sites that would need this feature probably already have a load balancer in front (as implied by having multiple server banks), the load balancer may be able to handle this for you without any servlet-container-specific features.

    Hypothetically-speaking, if Tomcat were to have this feature, how would you like it to behave? Once an admin sets the “no new sessions” flag, all requests that need new sessions return 503?

  • esavage

    Good point. I guess I was stuck in the mindset that load balancers are “hardware” and they are rarely touched unless your network architecture changes.

    However, some sites I’ve worked with currently and in the past do not have HTTP Load Balancers, just network-level load balancers, and they rely on the web servers to deal with things like sticky sessions. In this case I think this flag would be at the connector level. A 503 would be appropriate, but if the flag was set on the connector/HTTP server, those requests shouldn’t happen.

    An additional case would be where session (memory) load is more important to balance than network traffic, in which case the container would be the only source of this information.

    That said, I think your solution is the preferred one. My question would be, which load balancers have this feature, with no/minimal hackery?

  • httpd’s mod_proxy_balancer has session stickiness. I think nginx has a module to support this as well, but I’m not sure. Resin’s got that LoadBalanceServlet thing (http://www.caucho.com/resin-3.0/config/balance.xtp#resin) which support sticky sessions and is further pretty easy to hack in Java. There are probably others, too. I haven’t played in this area with hardware load balancers, but maybe some of them offer support for this.

    You make a good point about network-level load balancers, none of the above would help there.