On Thu, 2007-03-29 at 19:00 +0200, Joan Balagueró wrote: > Hello, > > Finally I've decided to have just 1 instance of > MultiThreadedHttpConnectionManager, that is used for N instances of > HttpClient. > > The maxConnections and setStaleCheck depends on > MultiThreadedHttpConnectionManager, but the connection and response timeout > and cookie policy are different for each HttpClient instance. > > With this design, the following code is wright? >
Joan, Please note that even though an HTTP connection manager instance can be shared by many HttpClient instances, the default values of the last HttpClient instance always apply: http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpClient.html#127 > // Multithreaded pool > MultiThreadedHttpConnectionManager mhcm = new > MultiThreadedHttpConnectionManager(); > mhcm.getParams().setMaxTotalConnections(20); > mhcm.getParams().setStaleCheckingEnabled(true); > > // First instance of httpClient > HttpClient objHttp1 = new HttpClient(mhcm); > objHttp1.getParams().setConnectionManagerTimeout(1); > objHttp1.getHttpConnectionManager().getParams().setConnectionTimeout(connect > ionTimeout); > objHttp1.getHttpConnectionManager().getParams().setSoTimeout(responseTimeout > ); > objHttp1.getParams().setCookiePolicy(CookiePolicy.RFC_2109); > > // Second instance of httpClient > HttpClient objHttp2 = new HttpClient(mhcm); > objHttp2.getParams().setConnectionManagerTimeout(1); > objHttp2.getHttpConnectionManager().getParams().setConnectionTimeout(connect > ionTimeout); > objHttp2.getHttpConnectionManager().getParams().setSoTimeout(responseTimeout > ); > objHttp2.getParams().setCookiePolicy(CookiePolicy.RFC_2109); > > > And following just some doubts I have. Certainly I've read a lot about > HttpClient but the hierarchy is not still clear for me. > > 1. When I do " > objHttp.getHttpConnectionManager().getParams().setSoTimeout(responseTimeout) > ", I'm applying the response timeout just to the connections of objHttp1 or > to all connections of MultiThreadedHttpConnectionManager? > By doing so you set the _default_ value of the SO_TIMEOUT > 2. And how can the reuse of connections work if objHttp1 and objHttp2 has > different connection parameters (different timeouts...)? > The SO_TIMEOUT always gets reset to its default value upon the connection lease from the connection pool. > 3. And what's the difference between > objHttp.getHttpConnectionManager().getParams().setSoTimeout(responseTimeout) > and > objHttp.getParams().setSoTimeout(responseTimeout);? > The former applies to HTTP connection instances only. The latter applies to HTTP connection instances and HTTP method instances. http://jakarta.apache.org/commons/httpclient/preference-api.html#HTTP_parameter_hierarchy > 4. And if it exists a "objHttp.getParams().setSoTimeout(responseTimeout)", > why not exists a > "objHttp.getParams().setConnectionTimeout(responseTimeout)"? > The connect timeout does not make any sense on the HTTP method level as execution of an HTTP method does not necessarily imply opening of a new connection. Hope this helps Oleg > > I hope that your response clarify me these points in order to work ok with > your library. > > Thanks in advance. > > Joan. > > > -----Mensaje original----- > De: Roland Weber [mailto:[EMAIL PROTECTED] > Enviado el: miércoles, 28 de marzo de 2007 18:44 > Para: HttpClient User Discussion > Asunto: Re: QUESTION ABOUT MultiThreadedHttpConnectionManager > > Hello Joan, > > > The instante of MultiThreadedHttpConnectionManager should be unique for > all > > httpclient instances? > > It depends. You can improve resource usage by having a single > connection manager. Then again, you don't necessarily need > different HttpClient instances in the first place. > > > I want to have N different instances of httpclient (for N webservices), > > because every instance has different connection parameters > (maxconnections, > > timeouts, …) > > If max connections (total, per host) is different, then you need > separate MTHCM. Because that's what a connection manager does. > > Almost everything else is handled elsewhere and would not prevent > you from using a single MTHCM. > > > hope that helps, > Roland > > > --------------------------------------------------------------------- > 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]
