Santosh, There's nothing wrong with this approach. In HttpClient 2.0.x the connection is the only component worth reusing. However, as of version 3.0 HttpClient sports a new preferences architecture. So, along with HttpClient instance one will end up losing all the preferences associated with it. What's the problem with just keeping one global instance of HttpClient, especially since you already have a global connection pool?
What particular scalability problems are you having? Oleg On Tue, Nov 30, 2004 at 07:23:02PM -0600, Santosh Haranath wrote: > In my requirement, I have a webserver scraping pages from couple of > other webservers. I implemented using > MultiThreadedHttpConnectionManager, which is created once in > application lifetime where as HTTPClient is created per request which > can happen parallel y using connectionmanager . > > In previous posts it has been suggested to make HTTPClient singleton. > But why ? If HTTPClient gets connection from > MultiThreadedHttpConnectionManager connection pool and gives connection > back to pool why will connection be gc'ed? what is benefit of saving > HTTPClient object? > > But still, I have performance and scalability problems with this > component . Please let me know your views. > > Thank you! > Santosh > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.289 / Virus Database: 265.4.3 - Release Date: 11/26/2004 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
