By using singleton HTTPClient do I risk data corruption ? I may have connection timeout value server specific and url user specific .
Oleg Kalnichevski wrote:
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]
-- 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]
