On Mon, 2012-01-23 at 01:49 -0800, Dvora wrote: > 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? > >
One can indeed reduce thread contention on HttpClient instance by using a separate instance of HttpClient per thread and get better performance (assuming one would still use a shared connection pool). However, I expect the difference in performance to be next to negligible. Oleg > 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] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
