tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@apache.org>
Subject RE: cvs commit: jakarta-tomcat-connectors/ajp/proxy proxy_ajp.c
Date Sat, 07 Aug 2004 05:46:29 GMT
 

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.

Mime
View raw message