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 <[EMAIL PROTECTED]> wrote: > > On 1/14/08, Sangjin Lee <[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 >
