Strange "long polling" problem.

Ian Hobson ian at
Thu Dec 1 23:28:03 UTC 2011

Hi All,

I am having a problem with my Chatroom, that uses the long polling 
module linked with nginx version 1.0.6

First the structure.
There are two http conversations going on with each client.
GETs, created by "on-load" and receiving the previous message, are 
issued to the long polling "activity" address.
When the data arrives, it updates the screen, as well as triggering the 
next "GET".  Note - there is a small time gap between one message being 
sent and the next being requested.

POSTS are triggered by user events. These send a separate XMLHTTPRequest 
to a php program - handlechat.php

handlechat.php  writes the relevant stuff to the database, and then 
issues a "curl" to write data to the "publish" address, and replies with 
an empty "200" reply.

It works 99.9% of the time.  Which is not quite 100%. :(

When it fails
     The client's GET is outstanding (reported by chrome)
     The database has the missed message
     The curl write to the publish address replies with first

queued messages: 1
last requested: 12 sec. ago (-1=never)
active subscribers: 2
queued messages: 1
last requested: 13 sec. ago (-1=never)
active subscribers: 2

I know both CURLs worked.  The "missing" message is received by the 
other user. It just is not received by the failing user.
If the failing user refreshes the screen, thus re-initialising 
everything he getst the missing message twice, once from the log
and once from the stalled message.

As part of my testing, I tried INCREASING the delay between getting an 
update and requesting the next. This made the problems much much worse.

It appears that messages posted after a reply is sent, and before the 
next request is received are not being sent on.

Note - I return the etag in the header, so I think they should be.

What is the correct method to over-come this problem?



Ian Hobson
31 Sheerwater, Northampton NN3 5HU,
Tel: 01604 513875
Preparing eBooks for Kindle and ePub to give the best reader experience.

More information about the nginx mailing list