All the comet solutions rely on holding the connection between the webserver open as long as possible, either by the client making a
POST request and then delaying sending the data, or the server sending a
GET response, again delaying the data.
Both of those have similar problems for the origin, namely consuming a socket and memory per connection, and possibly a thread, unless you are using something like Jetty continuations.
By placing a reverse proxy like Apache in front of Jetty, like apache each open connection between Jetty and the client will also consume a worker. Depending on which apache worker model you choose (for example
mod_worker_mpm) there will be limitations on the maximum number of connections your apache server can support. That is around a couple of hundred for
mod_prefork and is generally limited by the amount of physical memory each worker process consumes, to a few thousand with
mod_worker_mpm. If you are mixing
mod_worker_mpm with php you should research the options that your version of php was compiled with as there are known incompatibilities with php and
You will also have to be mindful of the timeouts in both Apache and Jetty. Comet style connections either simulate a slow
POST request, so you'll have to tune Apache to be lenient towards that, as well as the size of the request body.
GET style requests are also subject to timeout if nothing is transmitted from the origin server. You'll have to apply these timeouts on both sides of the reverse proxy connection, from the client to Apache, and from Apache to Jetty.
If I was deploying a solution like this I would either place the Jetty based Comet service on a different domain, using a load balancer to proxy multiple Jetty backends for added capacity and reliability, or I would use a different reverse proxy, say HAProxy, to act in Apaches stead, and direct requests to the various backends (Apache, Jetty), based on the URL.