How scalable is the Lift framework's comet/reverse ajax?

Question

I recently learned scala and about to start working/learning Lift framework. Going through the Features and getting started with the framework, I had seen some amazing capabilities of the framework including the reverse ajax and comet. Earlier in my experience I had really really bad experience with the reverse ajax which never scaled. If I choose lift framework for any development this will be the reason. My Question here is how mature is the technology and the product and how much scalable is it using lift on tomcat? Comparing to servlet spec 3.0 which one is better for this purpose, wait for servlet spec 3.0 or get started using lift?

Answer 1

Reverse AJAX is Comet. They're just two different names for the same thing. As for the root of your question...

The scalability of Lift's Comet support depends a lot on the servlet container. You really need a container which supports continuations natively. Jetty is the one I'm familiar with, but I'm pretty sure there are others. By having continuation support at the container-level, you're able to avoid locking a thread-per-client, which is where most of Comet's scalability issues stem from.

In other areas of scalability, Lift's CometActor is the generic abstraction around a single client with an active long-poll. Because this abstraction is an actor, it can be handled within the existing actor framework (Scala stdlib for Lift 1.0.x, or Lift actors on 2.0). This too avoids the issue of thread scaling and ensures that pending updates will be queued in an orderly fashion.

In short, Lift's Comet support is about as scalable as Comet can be. There are of course intrinsic overheads associated with the technique. You're never going to be able to avoid committing at least one socket per client. However, Lift (along with a continuations-enabled container) is able to mitigate any non-essential overhead right out of the box.