geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee" <sjl...@gmail.com>
Subject Re: Is there a problem with AsyncHttpClient connection reuse?
Date Mon, 14 Jan 2008 22:17:27 GMT
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.

Thanks,
Sangjin

On 1/14/08, Jarek Gawor <jgawor@gmail.com> wrote:
>
> On 1/14/08, Sangjin Lee <sjlee0@gmail.com> 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
>

Mime
View raw message