Or: How to get a good cgi + long polling setup?
We have a (mod_perl) web application running under Apache 2. Keeping existing code as-is, we now also want to do some long-polling, but then we'll occupy a worker for every long-poll request underway and that doesn't work for us.
I already know how to write an application that can handle many requests simultaneously to handle the long-polling/comet requests, but it is important that we have only a single IP port open to the outside world.
Enter reverse proxy with mod-proxy. I've seen conflicting information about whether mod-proxy waits/blocks for the result to come back, doesn't wait/block, or whether it depends on "Transfer-Encoding: Chunked". Which is true, and what does "Tranfer-Encoding" have to do with anything?
I've also read that nginx is better than Apache2 at reverse proxy. I'm ok with putting nginx in front of apache, but Apache2 alone would be simpler. I've also read reports that file download/uploads, error pages, logging could be problematic. Any gotchas here?
Say our server for handling comet requests is listening to localhost:8080.
So will I be able to create a scalable setup with many long polling clients with Apache + mod_proxy only? With nginx in front of Apache and our comet server?
This is similar to Understanding mod_proxy and Apache 2 for writing a comet-server, but not quite the same question.
Apache Httpd uses thread-per-connection model, and will run out of threads very fast with long polling. I've hit this problem in production with httpd working as reversed proxy, and it seems there is no way to make long polling work with httpd.
Consider using either nginx (for non-java servers) or jetty (as j2ee servlet container) they both use multiple requests per thread model, and are not affected by this problem.