Hello, 1. Ok. But with HttpClient 4.2, ConnManagerParams.setTimeout(this.objHttpParams, 1); is deprecated. What should I use instead for PoolingClientConnectionManager?
2. Well, in fact my app is a proxy for webservices. And I really can handle 1000 to 1500 concurrent requests. But the problem is the same: I need the whole response to continue the process, then I have to block until receiving it. I suppose that I'll have to make tests under heavy load to decide which pool works better. Thanks, Joan. -----Mensaje original----- De: Oleg Kalnichevski [mailto:[email protected]] Enviado el: viernes, 29 de junio de 2012 17:43 Para: HttpClient User Discussion Asunto: RE: AsyncHttpClient On Fri, 2012-06-29 at 17:06 +0200, Joan Balaguero wrote: > Hello Oleg, > > Thanks. Just a couple of questions: > > 1. Referring to the ConnectionPoolTimeout, I though that in the constructor > PoolingClientAsyncConnectionManager, the last two parameters > (timeToLive+timeUnit) represented the connectionPoolTimeout, but it seems > that I was wrong. Then what is the meaning of this two parameters? Because in > the PoolingClientConnectionManager I'm using them as ConnectionPoolTimeout.. > If they are not for this, how can I set the connectionPoolTimeout in the > PoolingClientConnectionManager (not async)? > 'Time to live' parameter determines the maximum period of time a connection can be kept alive (as long as keep-alive period is not explicitly set by the server in the response message). Connection request timeout (connection pool timeout) is the maximum period of time the client spend waiting for a connection to be leased from the pool. > 2. In my app, when I send a request using AsyncHttp, immediately I have to > block with future.get() because I cannot do anything in the main thread until > receiving the response. This response is an xml document that need to be > parsed, and I cannot do it until having the whole document. In this > scenario, where I use AsyncHttpClient in "blocking" mode, is it still make > sense to use AsyncHttp? If it has sense, what would it be the advantages of > this async model respect to the traditional blocking http client? Or in what > conditions would be better to use Async instead of Sync? > Blocking HttpClient is a much better choice for 95% of client side scenarios. Not to mention it is significantly faster than its non-blocking version. HttpAsyncClient is needed only when having to deal with thousands of concurrent connections most of which stay idle most of the time. Effectively HttpAsyncClient should be primarily used for building HTTP proxies and gateways. In your case I see no reason of what so ever for using an async client. Oleg > Thanks, > Joan. > > -----Mensaje original----- > De: Oleg Kalnichevski [mailto:[email protected]] Enviado el: viernes, > 29 de junio de 2012 16:47 > Para: HttpClient User Discussion > Asunto: Re: AsyncHttpClient > > On Thu, 2012-06-28 at 17:45 +0200, Joan Balaguero wrote: > > Hello, > > > > > > > > I’m trying to develop an AsyncHttpService class equivalent to my > > HttpService class, which uses the ‘PoolingClientConnectionManager’. > > After working with it, I have some doubts: > > > > > > > > 1. When I create the schemeRegistry: > > > > SchemeRegistry schemeRegistry = new SchemeRegistry(); > > > > schemeRegistry.register(new Scheme("http", 80, > > PlainSocketFactory.getSocketFactory())); > > > > schemeRegistry.register(new Scheme("https", 443, > > SSLSocketFactory.getSocketFactory())); > > > > > > > > And now: > > > > AsyncSchemeRegistry asyncSchemeRegistry = new > > AsyncSchemeRegistry(); > > > > asyncSchemeRegistry.register(new AsyncScheme("http", 80, ?)); > > > > asyncSchemeRegistry.register(new AsyncScheme("https", 443, ?)); > > > > > > > > I don’t understand what a LayeringStrategy is, and how I can pass it > > to the AsyncScheme constructor. > > > > > > You can pass an instance of SSLLayeringStrategy in case you need to > customize the SSL context or the way SSL is 'layered' over plain > TCP/IP > > > > > > > > > 2. How can I set the ‘ConnectionPoolTimeout ‘? > > > > HttpAsyncClient presently does not support a separate timeout for connection > lease requests. It uses connect timeout value when obtaining a connection > from the pool. > > > > > > > 3. With HttpClient, to set connection and response timeout, > > cookies, … I use ‘HttpParams’. What’s the recommended way in Aysnc? > > HttpParams? > > IOReactor? > > > > Exactly the same. > > > > > With HttpClient: > > > > HttpConnectionParams.setConnectionTimeout(this.objHttpParams, > > connectionTimeout); > > > > HttpConnectionParams.setSoTimeout(this.objHttpParams, > > responseTimeout); > > > > HttpClientParams.setCookiePolicy(this.objHttpParams, > > CookiePolicy.BEST_MATCH); > > > > > > > > With Async? > > > > Same. > > > this.ioReactorConfig.setConnectTimeout(connectionTimeout); > > > > this.ioReactorConfig.setSoTimeout(responseTimeout); > > > > And cookies? > > > > > > There is no need to meddle with the I/O reactor and its configuration. > With a few exceptions HttpAsyncClient can be configured using HttpParams > exactly the same way as HttpClient. > > > > > > > > > 4. Do ‘stale check’ and ‘expect-continue’ and ‘RetryHandler’ exist > > in AsynHttp? > > > > > > The stale connection check is not applicable to HttpAsyncClient. There's no > need for stale connection check with NIO. The 'expect-continue' is fully > supported. Automatic retries are presently not implemented. > > > > > 5. To shutdown the pool, should I use > > PoolingClientAsyncConnectionManager.shutdown() or > > ConnectingIOReactor.shutdown()? > > > > > > ClientAsyncConnectionManager#shutdown() > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > ----- > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versión: 2012.0.2180 / Base de datos de virus: 2437/5099 - Fecha de > publicación: 06/28/12 > > > --------------------------------------------------------------------- > 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] ----- No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versión: 2012.0.2180 / Base de datos de virus: 2437/5099 - Fecha de publicación: 06/28/12 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
