>From performance point of view, isn't it preferred creating new HttpClient instance per thread? I'm asking because I saw in the source code a synchronized block at AbstractHttpClient.execute() so I guess threads sharing the same instance will be blocked at that point, Am I right?
olegk wrote: > > On Mon, 2011-05-16 at 21:10 +0000, KARR, DAVID (ATTSI) wrote: >> > -----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? >> > > Both are thread-safe but the default can have only one connection at a > time, so requests can be executed sequentially, one by one, whereas > ThreadSafeClientConnManager can execute multiple requests over multiple > connections concurrently. > > ThreadSafeClientConnManager was unfortunately a very bad choice of name > for the class. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://old.nabble.com/Confused-about-guidelines-for-using-HttpClient-instance-in-multiple-threads-tp31632538p33186920.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
