There are two really interesting blogs recently that demonstrate Comet and its increasing adoption. The first one, Comet Slideshow, uses the Bayeux Protocol (Dojo on the client side, Grizzly on the server side) to demonstrate a really nice and simple slide show.

Since Bayeux’s goal is to be portable across Web Servers, I suspect the demo should also work with Jetty. Hopefully the Cometd team will have some compatibility tests soon so applications stay portable.

The next application demonstrates a tic-tac-toe game, which seems to challenge the chat for the most popularly demonstrated Comet application…..nothing fancy, except the clients can be written using the Rails (Ruby or JRuby) and Grails (Groovy) scripting languages.

Comet is rocking JavaOne 2008! And especially on Wednesday. 1100 attendees listened to Asynchronous Ajax for Revolutionary Web Applications. And the BOFs are quite packed as well: (BOF-5661) Comet: The Rise of Highly Interactive Web Sites (Alex Russell and Joe Walker) had ~600 attendees, (BOF-4922) Writing Real-Time Web Applications, Using Google Web Toolkit and Comet ~600 attendees and (BOF-4922) Using Comet to Create a Two-Player Web Game, ~200 attendees. The Day One keynote also demonstrated a tic-tac-toe demo which under the hood uses Comet. So, the buzzword for JavaOne 2008 is Comet!

There are more and more Comet examples available on the web using Java. Here’s a list of demos based on DWR, ICEFaces, GlassFish, Jetty, Tomcat, Lightstreamer, and TIBCO:

• DWR: Getting Started with Comet support in DWR. Run on Jetty and Grizzly/GlassFish
• ICEFaces: Uses JavaServerFaces, Ajax and Comet to share your slides using WebMc. Run on Tomcat and Grizzly/GlassFish
• GlassFish: Bayeux, JavaScript and JSON based Comet samples
• Jetty: Cometd/Bayeux demo running on Jetty
• Tomcat: Simple Chat demo running on Tomcat
• There are a number of Lightstreamer demos
• TIBCO stock portfolio demo

I’m sure I’m missing some, so please add yours to this discussion.

JavaOne 2008 is around the corner, and here is a list of Comet-related talks you don’t want to miss. Interestingly, most of them will be presented by contributors to Comet Daily! They all look very interesting, but I strongly recommend TS-296823, where I will discuss Comet in general, from client side libraries like Dojo / Bayeux, DWR, and ICEfaces to server side support like Grizzly, Jetty and Tomcat.

• (TS-296823) Asynchronous Ajax for Revolutionary Web Applications (Jean-Francois)
• (BOF-5661) Comet: The Rise of Highly Interactive Web Sites (Alex Russell and Joe Walker)
• (BOF-4922) Writing Real-Time Web Applications, Using Google Web Toolkit and Comet (Jean-Francois)
• (BOF-4922) Using Comet to Create a Two-Player Web Game (Jean-Francois)

And the following ones will talk about their implementations:

• (TS-4883) Advanced Java™ NIO Technology-Based Applications Using the Grizzly Framework (Jean-Francois)
• (BOF-5114) The Jetty Web Server (Greg Wilkins)
• (TS-5030) Building Secure Mashups with OpenAjax (Jon Ferraiolo)

Web applications using Comet (a.k.a. Ajax Push) are growing in popularity. Although there is a growing number of articles on Comet, the current literature mostly focuses on how to build a JavaScript client, how a web application can be developed using a particular web server, or why you should use Comet, etc. Little has been said so far on the new problems that push operations might introduce. Problems unfortunately do exist, and might not be discovered until very late in the development cycle. In this article, I would like to discuss one issue I’ve frequently seen over the last year, which is what I call Delayed Push Operations (DPO). But before that, let’s just refresh our mind with some basic things.

Polling, Long Polling and HTTP Streaming

The most popular technique used with Ajax currently is called polling. With polling, an Ajax application will poll the server for data every time the content of the page requires an update. Most of the responses the server returns will not contain any data (blank response).

The second technique, considered the emerging technique, is called long polling (a.k.a. Comet), where you open a persistent connection and wait for the server to execute the push operation. In contrast with the polling technique, the server never sends a blank response, and instead waits until data is available to initiate a push operation.

Finally, the third technique is called HTTP streaming. HTTP streaming is similar to the long polling technique except the connection is rarely closed, even after the server executes push operations. With HTTP streaming, an Ajax application will only send a single request and receive chunked (partial) responses as they come, re-using the same connection for a really long time.

Simple enough. Now with long polling and HTTP streaming, many problems might happen when the server executes its push operations. The one that happens frequently is what I call Delayed Push Operations, or DPO.

What is Delayed Push Operations (DPO)?

Before explaining delayed push operations, let me describe what a push operation is. A push operation is the phase when a server-side component decides to send message(s) back to the client using a long polling or HTTP streaming connection. The server component decides, most of the time, to execute the push operation based on some application-specific logic. As an example, the server-side component of a stock quote application will execute push operations every time new quotes are available, and a server-side component of a chat application will execute push operations as soon as a new chat message becomes available. The server component maintains a pool of long polling/HTTP streaming connections, and as soon as an event occurs, it starts push operations by updating the connection pool with the new data.

Delayed push operations happens when the client is not getting updated as fast as it should be or expects to be. As an example, a stock quote application that starts getting updates every 5 seconds instead of every 1 second will suffer the delayed push operations problem. Of course, the application still works, but the promise of real time data that Comet offers is severely impacted, and more importantly, the perception that the application provides real time data is severely reduced. Worse, most of the time the problems will be discovered very late in the development cycle, and having to re-architect the server-side component to fix the delayed push operations problem might impact the application architecture, its delivery schedule and again, perception of Comet as a real time technology.

When Does DPO happen?

Delayed push operations are measurable when the following symptoms start appearing:

1. Server congestion: The OS/server/application is running out of resources. This problem arises most of the time when there are too many simultaneous connections open on a single server.
2. Client congestion: The clients aren’t reading messages fast enough and the server is blocked while waiting for clients to read the messages. If the server uses a single threaded strategy for executing its push operations, one client might delay other clients as the server is waiting for that one client to read its messages.
3. Data congestion: The server is not able to write messages fast enough, so messages accumulate and push operations are delayed.

The problem of delayed operations is better understood for applications that use the polling technique instead of long polling or HTTP streaming. Server and client congestion solutions are widely defined and used, and multiple solutions exist, like using load balancers, clusters of servers, etc. With the polling technique, you rarely suffer data congestion directly, but rather as a consequence of server/client congestion. Hence as soon as you fix your server/client congestion, your data congestion usually goes away.

Unfortunately, that’s not the case with the long polling and HTTP streaming techniques. With those techniques, a small number of client connections might easily produce data congestion that produces delayed push operations. How? In a Comet application, all long polling connections to the server might eventually share information amongst each other. To put it differently, all long polling connections might be virtually connected to each other. When one client sends data, the server will respond and then start its push operations, updating all the long polling connections virtually connected to each other. In comparison, with the polling technique, the server just needs to send a response back, with no extra operation.

So far so good. Now if all clients decide to respond to the first server push, the server will ends up having to initiate push operations for every client’s response. The server will work on executing its first push operations and the amount of operations it will have to execute will grow as soon as a single message is pushed. There might not be any data congestion for a relatively small amount of clients, but every new client added will increase the probability of creating data congestion. For a small load the problem might never show up, but increasing the number of virtually connected connections will eventually produce data congestion.

Want to see how this can happen? Just take a look at the JMaki Grizzly Comet demo or the Jetty Cometd demo. Those applications are quite cool to demo. Now just open more and more browsers and see how bad the situation can become. Just start moving things and see how other browser are updated….now find 50 of your friends and ask them to move things simultaneously…boom!!

Solutions

There is no simple solution to avoid data congestion and reduce the probability of delayed push operations. There are several ways to reduce the probability of creating data congestion:

• Aggregate messages: Instead of executing a server push operation every time new data is available, aggregate messages and execute a single push operation containing multiple messages.
• Filter messages: Some messages might not need to be delivered under load and can be dropped.
• Delay messages: Some messages might not need to be delivered in real time, so delaying them can reduce the probability of producing delayed push operations.

Conclusion

When writing Comet-based applications, it is important to reduce the probability of delayed push operations. Since Comet is a new technology and optimal solutions for reducing delayed push operations still need to be explored, aggregating, filtering, or delaying push operations might significantly improve the usability of your application under load.

This year Comet is more and more popular, and it is reflected at conferences in terms of the number of sessions talking about Comet. This is interesting, as it wasn’t the case last year. Just for fun, here is a unofficial list of conferences where Comet was discussed in 2007, and the number of Comet sessions for each:

1. ApacheCon US (2)
2. JavaOne (2)
3. AjaxWorld/East (2)
4. AjaxWorld/West (2)
5. FISL(1)
6. JavaPolis (1)

That’s for the entire year. For 2008, we’re only in March and already we have:

1. JBossWorld (1)
2. ApacheConf EU (1)
3. JavaOne (6)
4. AjaxWorld/East (6)
5. FISL (3)

The rest of 2008 looks promising…..

Comet scrubs off old technologies to let imagination and potential shine to the face of the world. Comet indeed consists of a new technology that gives “real time” applications a new meaning. Stop! Just start thinking of everything that can come true if you don’t need content piggybacking anymore. Imagine receiving what is desired with no need to request. This is what Comet brings into the sky: a new era that will enlighten the dark ages of the Ajax Knight .

Up to Comet, web designers have had to cleverly invent ways on the browser side to palliate the slowly delivered responses of a web server. Now Comet shifts all the burden from the client side to the server side. Why? Because even if Comet promises real time content updates, the burden of delivering those updates on time falls on the web server.

The currently known “click-request-wait-push-response” real time protocol failed to deliver on time responses to the client so many times that we are looking for a new expression to describe the new simple “push-receive protocol”.

However marvel, just like trouble, never comes alone . Comet also comes with a tail: performance challenges!

An application might claim to use Comet, but performance-wise are server pushes really delivered on time?

Let’s use the “infamous” chat example. With 10,000 connected clients, will the content really be delivered in real time? Of course, if you have a dedicated web server per application, this problem might never arise… but we all know this is not the case. The first 700 users might get a decent responses time, but what about the remaining outliers? They might get the most decent responses, but too late. Delayed response could be tolerable for a chat, but as soon as we envision more demanding applications, like stock quote or online games, Comet may fail to deliver what the web designer is expecting: real time pushes from the server.

Most of the Comet actual literature (Comet Daily included ) focus on the client side of Comet, but new challenges are now on the server side: how can the push operations be efficient enough to deliver what Comet is meant for? Web designers must start thinking right from the beginning about how their applications will execute the push operations without too much contention. Web servers that claim to support Comet must offer the tools and APIs to let web designers efficiently deliver what Comet is all about: real time pushes.

With Comet, challenges remain but their nature changes. So for now start thinking of all the new applications while waiting for my upcoming contributions to Comet Daily that will try to orient you to a new frame of thoughts towards efficient design of Comet applications.