[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-users
Subject:    Re: Using HttpAsyncClient completely asynchronously, and shutdown client/request appropriately.
From:       Oleg Kalnichevski <olegk () apache ! org>
Date:       2013-02-05 22:44:49
Message-ID: 1360104289.3744.14.camel () ubuntu
[Download RAW message or body]

On Tue, 2013-02-05 at 23:41 +0100, Oleg Kalnichevski wrote:
> On Tue, 2013-02-05 at 15:44 -0500, Arian wrote:
> > Hey all, I've gotten further along and had some followup questions ...
> > 
> > I have a single httpclient instance now for the web application...
> > and I am now using the PoolingClientConnectionManager so I can easily do
> > Multiple-Threads at same time if needed, and now using the regular
> > HttpClient (ditched the AsyncClient as suggested in my situation) .
> > I tested and I think the web app works as intended with no expected
> > failures (have not done a load-test though).
> > I was able to set a breakpoint in run() and see two threads do their work
> > at same time.
> > 
> > 1. I was just curious if I need to consume the entity in my Thread's run()
> > and/or call releaseConnection () to do any 'cleanup' like how i do at the
> > end of my PostThread class below  ...
> > Note: I want the client available since every minute a new request to send
> > could come in. Not sure if this affects if i want to 'releaseConnection()'.
> > 
> 
> By consuming the content entity you enable HttpClient to keep the
> connection alive and re-use it for subsequent requests.
> #releaseConnection makes sure resources associated with connection get
> deallocated but it makes no effort to keep the connection re-usable. So,
> you might want to use the latter for happy flow and the former for
> exceptional cases.
> 

Sorry. Other way around. 

Oleg

> ---
> HttpResponse response1 = httpclient.execute(httpGet);
> try {
> HttpEntity entity1 = response1.getEntity();
> // do something useful with the response body
> } finally {
> httpGet.releaseConnection();
> }
> ---  
> 
> If you always want to try to salvage the connection you can do it like
> this
> ---
> HttpResponse response1 = httpclient.execute(httpGet);
> try {
> HttpEntity entity1 = response1.getEntity();
> // do something useful with the response body
> // and ensure it is fully consumed
> } finally {
> EntityUtils.consume(entity1);
> }
> ---
> 
> > 2. I might have 1 new request/thread being created every minute (possibly
> > around same time too)... The connection to 3rd party might be slow (3second
> > response max... but dont want user to experience it) hence why just kicking
> > it off to a new thread as suggested.
> > What would be optimal values for cm.setMaxTotal(?);
> > cm.setDefaultMaxPerRoute(?);? be with above parameters, and possibly lets
> > say coincidence 5 people spawn a new thread at same time? Not sure if this
> > is also useful, but the url will stay the same... only the params passed to
> > the HttpPost via the UrlEncodedFormEntity will change.
> > Would MaxTotal be 5 since maybe I want 10 threads available to do requests
> > at any given moment?
> > I didn't see documentation on what those really set (but found some code
> > online which says to modify it or will only have 2 threads available in the
> > pool or something like that):
> > http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/PoolingClientConnectionManager.html#setMaxTotal%28int%29
> >  
> > 
> 
> Those settings tend to be application specific. There is no one general
> rule that works in all cases.
> 
> Oleg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]