Graham Leggett wrote: > > > Bounding to client connection is not needed(?). > > Since AJP can serve multiple request trough the same > > backend connection, no need to create separate conn_rec. > > For now comment out all the set/get module config. > > Is there still a reason why in proxy_http the backend > connection still needs to be broken when the frontend client > breaks the connection? This behaviour was originally done > like that because there was no pool (until now :)). >
I don't think so. The backend connection will have to be made using HTTP/1.1 no mater what the client actually wants. If that doesn't break any RFC then we can use that. Well, I've designed the connection pool to support that, but I've choose the conservative approach (for now :)). > In theory, as long as the backend connection is made using > HTTP/1.1, and has keepalive enabled, that keepalive > connection could be reused for other frontend connections > from different clients. > Sure, but only if that's really allowed. I'm a little bit concerned about ssl connections, but in that case we can make a decision and either bound to the client or not. I can make a configurable test solution that will allow us to test how this 'unbound mode' behaves in real-world situations. It is very easy to do (just change conn->close_on_recycle to 0). Right now it's hard-coded inside each scheme handler, but it can be set as configurable option. For serving static content from cluster of backend servers it wouldn't make a difference, not sure for other contents. Of course it would be a performance boost not needing to reconnect all the time, but rather when the backend disconnects. MT.
smime.p7s
Description: S/MIME cryptographic signature
