> -----Original Message-----
> From: Moore, Jonathan (CIM) [mailto:[email protected]]
> Sent: Monday, May 16, 2011 1:15 PM
> To: HttpClient User Discussion
> Subject: Re: Confused about guidelines for using HttpClient instance in
> multiple threads
> 
> All this is trying to say is that you don't need a new
> DefaultHttpClient
> instance for every thread, particularly if you only have one connection
> pool. Multiple threads can use the same DefaultHttpClient to execute
> HTTP
> requests.
> 
> However, when the singleton instance passes out of scope, a clean
> shutdown
> requires also shutting down the ConnectionManager.
> 
> Does that help?

Then what's the difference between using the default client connection manager, 
as opposed to the ThreadSafeClientConnManager?

> On 5/16/11 4:08 PM, "KARR, DAVID (ATTSI)" <[email protected]> wrote:
> 
> >I must be misunderstanding what I'm reading, but the HttpClient doc
> seems
> >to have conflicting information about how to use an HttpClient
> instance
> >from multiple threads.
> >
> >In section 2.9, "Multithreaded request execution", there's the
> following
> >statement:
> >
> >"When equipped with a pooling connection manager such as
> >ThreadSafeClientConnManager, HttpClient can be used to execute
> multiple
> >requests simultaneously using multiple threads of execution."
> >
> >In section 5.1, "HttpClient Façade", there is the following statement:
> >
> >"DefaultHttpClient is thread safe. It is recommended that the same
> >instance of this class is reused for multiple request executions. When
> an
> >instance of DefaultHttpClient is no longer needed and is about to go
> out
> >of scope the connection manager associated with it must be shut down
> by
> >calling the ClientConnectionManager#shutdown() method."
> >
> >Can someone explain this seeming discrepancy?
> >
> >
> >
> >---------------------------------------------------------------------
> >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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to