Home > Atmosphere > Improving HTTP Long Polling performance using ETag

Improving HTTP Long Polling performance using ETag

The Comet technique called “long polling” is the most widely used technique. In this blog I will explain a way optimize this technique using the well know etag HTTP header using the Atmosphere Framework.

There are many ways to optimally implement the long polling technique, and how events get cached on the server side. In most frameworks/applications, events are getting cached to prevent clients from missing them when reconnecting. When the client reconnect, missed events are retrieved using custom techniques like:

  • Use a special header containing the last time the client has connected. Based on that time stamp, the server can retrieve all events that occurred after that time.
  • Use a special header container an event counter, and retrieve the missed events based on that count

A better approach consist of using the well know Etag HTTP header. Wikipedia defines Etag as:

An ETag, or entity tag, is part of HTTP, the protocol for the World Wide Web. It is one of several mechanisms that HTTP provides for cache validation, and which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. .

That’s exactly what we need to optimize our long polling request, e.g use an Etag to:

  1. Decide when to long poll the connection
  2. Decide to long poll the connection even if some events where cached since the last connection. Aggreate the cached events with the new one.
  3. Avoid long polling the connection, return immediately.

Before going into the details, let’s describe how an ETag can be generated from the server side. A simple but very powerful way to generate an Etag is to generate it based on a MD5 Message-Digest Algorithm. That value will be regenerated every time events get cached, and that value will be used as an Etag send back to the client.

The client will use the ETag value and send it back to the server using the “If-None-Match” header. On the server side, the value will be compared with the last generated ETag value. If the client’s ETag match the server one, that means no event occurred since the last time the client was connected. Two actions can be taken:

  • Long poll (suspend) the connection until the ETag gets regenerated, which means a new events occurred on the server side.
  • Return an HTTP status code of 204: The server successfully processed the request, but is not returning any content. Returning a 204 could be used when the number of long polled connections is really high to prevent out of memory errors or to reduce the memory footprint. In that case the client could reconnect later (polling the server).

If the ETag values aren’t matching, that mean events occurred since the last time the client connected. Two actions can be taken:

  • Sent back the cached events to the client. In that case we don’t long poll the connection.
  • long poll the connection (suspend) until the next events occurs. Then combine the cached events with the new one and resume the connection.

Note that every time a new events occurs, a new ETag value needs to be regenerated.

Now how can this be implemented? Using the Atmosphere Framework it is as simple as:

public SuspendResponse optimalLongPolling(final @Context Request request){
    final String eTagString = server.getETag();
    final Response.ResponseBuilder responseBuilder =
        request.evaluatePreconditions(new EntityTag(eTagString));

    if (responseBuilder != null){
        return new SuspendResponse.SuspendResponseBuilder()
                .addListener(new AtmosphereEventsListener())
                .period(30, TimeUnit.MILLISECONDS)
    } else {
        throw new WebApplicationException(

Very simple.

For any questions or to download Atmosphere Client and Server Framework, go to our main site, use our Nabble forum, follow the team or myself and tweet your questions there! You can also checkout the code on Github.

Categories: Atmosphere
  1. Subbu Allamaraju
    June 16, 2011 at 8:34 pm

    Couple of comments –

    a. The technique isnt specific to long polling.
    b. RFC 2616 is a better reference than Wikipedia.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: