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.
Rick
Thanks,
Sangjin
On 1/14/08, *Jarek Gawor* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
On 1/14/08, Sangjin Lee <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
