Is long polling possible in Google App Engine?

Question

I need to make application that needs to poll server often, but GAE has limitations on requests, so making a lot of requests could be very costly. Is it possible to use long polling and make requests wait for the maxium 30 seconds for changes?

Answer 1

I don't think long polling is possible. The default request timeout for google appengine is 30 seconds. In long polling if the message takes more than 30 secs to generate, then it will fail. You are probably better off using short polling.

Another approach is to "simulate" long polling withing the 30 sec limit. To do this if a message does not arrive within, say 20 sec, the server can send a "token" message instead of a normal message, requiring the client to consume it and connect again.

There seems to be feature request (and its accepted) on google appengine for long polling

Answer 2

Google AppEngine has a new feature Channel API, with that you have a possibility to build a good realtime application.

Another solution is to use a third part comet server like mochiweb or twisted with a iframe pattern.

Client1, waiting a event:

client1 --Iframe Pattern--> Erlang/Mochiweb(HttpLongPolling):

Client2, sending a message:

client2 --XhrIo--> AppEngine --UrlFetch--> Erlang/Mochiweb

To use mochiweb with comet pattern, Richard Jones has written a good topic (on google: Richard Jones A Million-user Comet Application).

Answer 3

We've tried implementing a Comet-like long-polling solution on App Engine, with mixed results.

def wait_for_update(request, blob):
    """
    Wait for blob update, if wait option specified in query string.
    Otherwise, return 304 Not Modified.
    """
    wait = request.GET.get('wait', '')
    if not wait.isdigit():
        return blob
    start = time.time()
    deadline = start + int(wait)
    original_sha1 = blob.sha1
    try:
        while time.time() < deadline:
            # Sleep one or two seconds.
            elapsed = time.time() - start
            time.sleep(1 if elapsed < 7 else 2)
            # Try to read updated blob from memcache.
            logging.info("Checking memcache for blob update after %.1fs",
                         elapsed)
            blob = Blob.cache_get_by_key_name(request.key_name)
            # Detect changes.
            if blob is None or blob.sha1 != original_sha1:
                break
    except DeadlineExceededError:
        logging.info("Caught DeadlineExceededError after %.1fs",
                     time.time() - start)
    return blob

The problem I'm seeing is that requests following a long-polling one, are getting serialize (synchronized) behind the long-polling request. I can look at a trace in Chrome and see a timeline like this:

1. Request 1 sent. GET (un-modified) blob (wait until changed).
2. Request 2 sent. Modify the blob.
3. After full time-out, Request 1 returns (data unmodified).
4. Request 2 gets processed on server, and returns success.

I've used wireshark and Chrome/timeline to confirm that I AM sending the modification request to the server on a distinct TCP connection from the long-polling one. So this snychronization must be happing on the App Engine production server. Google doesn't document this detail of the server behavior, as far as I know.

I think waiting for the channel API is the best hope we have of getting good real-time behavior from App Engine.