On 02/13/2006 09:12 PM, Jim Jagielski wrote: > Brian Akins wrote: > >>Jim Jagielski wrote: >> >> >>>Let's assume that you have Apache setup as a proxy and furthermore >>>it's configured so that /html goes to foo1 and /images goes >>>to /foo2. >>> >>>A request comes in for /html/index.htm, and gets proxied to >>>foo1, as it should; the connection is kept-alive, and a >>>request for /images/blarf.gif is requested; this should not >>>be sent to the just kept-alive server, but instead to >>>foo2... >> >>I see now. >> >>Does this apply even when using balancer? I mean, do we break the keep >>alive to backend? We should need to... >> > > > Yep, and that's why I think we close the connection each time; > we can't be assured that the next request will be for that > backend, so we have a held-open socket for who knows how long, > and without real connection pooling, we're wasting sockets.
What do you mean by "real connection pooling"? We actually have connection pooling via the apr reslist. The patch ensures that we return this connection to the pool such that it can be used by other clients that use this worker. Furthermore we have to keep the following two things in mind: 1. Closing the connection in proxy_util.c is badness as other protocols (e.g. ajp are designed to have very long living connections to the backend. If we keep on closing this, it would mean that mod_proxy_ajp would be no real alternative to mod_jk. 2. To be honest my view on the proxy code might be too "reverse proxy" driven, but on a busy reverse proxy the connection will be quickly reused by another client, so it makes perfect sense to me to keep it open. One critical thing I currently see on this path is a race condition with the keep-alive timeout timer on the backend. The backend could close the connection after we checked it in ap_proxy_connect_backend and before we sent the request in ap_proxy_http_request. That might be also an argument to sent a Connection: Keep-Alive header and evaluate the timeout token of a possibly returned Keep-Alive header by the backend. E.g. we could restablish the connection once we know that there is less equal then one second left before the timeout happens on the backend. Regards Rüdiger
