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. I see a couple of options: - Relax the current SessionCache implementation so it's no longer a singleton. - Make each AsyncHttpClient create its own SessionCache or make it an option of using the default session cache or its own
I am thinking we want to give it an option of using a default session cache or its own. What do you think? Thanks, Sangjin On 1/14/08, Rick McGuire <[EMAIL PROTECTED]> wrote: > > I haven't convinced myself that this is a problem yet, but it's worth > asking the question. The AsyncHttpClient has support for connection > reuse when making repeated connections to sites. Since these > connnections persist between instantiations of AsyncHttpClient > instances, there's a single static cache of the reusable connections > that is maintained. Selection from the session cache is made using the > host/port combination only, which means it's possible that a connection > that is reused by a client will get processed using the thread pool > configuration of the original connection client and not the current > requesting client. I suspect this is not an issue that can be that can > be easily detected or protected against, so the "fix" might just be a > word of caution added to the documentation on enabling connection reuse. > > rick >
