I am using nginx with the long polling module. When 0.7 something was
new, I compiled nginx with the long polling module and wrote my
application. It ran under Ubuntu for 18 months or so, without problem.
During this time I have not changed the code that handles messages or
startup. In fact, there are only two commits to the VCS.
About a month ago, I recompiled 1.0.6 with the long polling module using
the same script as before. And the application has started to show
intermittent errors.
Can anyone confirm that they are using the long-polling module with
1.0.6 without problems?
The symptom appears to be that if the second person to join the chat
room, does not send a message for 5 minutes and they do not receive one
in this time either, then they get timed out, and never receive a reply
to the read issued after the start-up phase.
Datum: Tue, 27 Sep 2011 00:10:40 +0200
Von: Thomas L. [email protected]
An: [email protected]
Betreff: Re: Does the long polling module work with nginx 1.0.6?
this server, so it’s insulated from any bad behaviour. I found the
or have a look at wandenbergs nginx-push-module, since version 0.3.0
(master branch) it also support long-polling and polling and its under
active develpment.
I put the push module into production for a while a few months ago and
suffered intermittent segfaults. It also has a couple of design
limitations that were problematic in my case. It doesn’t seem to be
under active development, so I doubt these issues will be fixed any
time soon.
But I wonder whether the module isn’t a poor solution architecturally,
in any case. I eventually dropped it and implemented long-polling in a
Node.js script. This turned out to be almost trivial – far faster
than trying to fix the module. Nginx is set up as a reverse proxy to
this server, so it’s insulated from any bad behaviour. I found the
stability and ease of maintenance of this design easily worth the
extra ~50 MB and CPU cycles.
Sorry. I can’t find any log from my substitutions module in your debug log.
And I find the possible problem. The response from backend server is
gzipped.
Maybe we could check the Content-Encoding response header
automatically in ngx_subs and if it’s gzip/deflate, just issue a
warning to error.log by default?