geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Is there a problem with AsyncHttpClient connection reuse?
Date Tue, 15 Jan 2008 09:54:20 GMT
Sangjin Lee wrote:
> Yes, if you used a different configuration for the SSL, then it would 
> be another issue.
> The questions are:
> - Do we want to even allow an option for using a shared connection cache?
> The benefit of a shared connection cache is ... just that; connection 
> reuse will be maximized for the given process.  However, the drawback 
> is that you may run into unexpected socket configuration/SSL 
> configuration behavior when you hand the connections to a different 
> client instance.
> - If we do allow it, what should be the default?
> I think *not* sharing the connection cache might be a better default 
> behavior.
Perhaps we should handle this the same way as the thread pools.  
Externalize the session cache and if you wish to share connections, 
provide the appropriate session cache to the AsyncHttpClient instance 
when it's instantiated.  If no cache is provided, then connection reuse 
is disabled for that client instance. 

> Thanks,
> Sangjin
> On 1/14/08, *Jarek Gawor* < <>> 
> wrote:
>     On 1/14/08, Sangjin Lee <
>     <>> wrote:
>     > It's a good point...  Currently the session cache is global, and all
>     > AsyncHttpClient instances are forced to share it.  The main
>     thing that
>     > concerns me is that as a result the connections will retain all
>     the socket
>     > properties that came from the AsyncHttpClient instance that
>     opened the
>     > connection.  This might not be intuitive to say the least.  For
>     example, one
>     > AsyncHttpClient instance opens a connection with TCP delay
>     disabled, and
>     > then another instance (this time with TCP delay enabled) comes
>     along and
>     > picks up this connection for reuse.  Contrary to what it
>     expects, it would
>     > get a connection with TCP delay disabled.
>     Right and this might be a bigger issue for SSL connections where you
>     might need to distinguish between cached connections based on the
>     client certs, CA certs, or enabled cipher suites (but I'm not sure if
>     these options can be set on the AsyncHttpClient).
>     Jarek

View raw message