Re: Disabling pooling of PoolingConnectionManager

[Murat Balkan]

it seems we cannot set a strategy to ClosableHttpClient. the only option
remaining is the header settings.

On Oct 18, 2016 10:41 AM, "Stefan Magnus Landrø" 
wrote:

> You could do both.
>
> From my experience all serious http server implementations respect the
> Connection: close header
>
> 2016-10-18 16:35 GMT+02:00 Murat Balkan :
>
> > I checked with the RFC and it seems if provided, "connection: close"
> header
> > is a MUST rather than SHOULD. So, it should not up to server
> > implementation. But I find the TTL and Strategy approaches safer as we
> have
> > some kind of control over them.
> >
> > On Tue, Oct 18, 2016 at 10:26 AM, Stefan Magnus Landrø <
> > stefan.lan...@gmail.com> wrote:
> >
> > > Why would you think so?
> > >
> > > 2016-10-18 16:10 GMT+02:00 Murat Balkan :
> > >
> > > > Thanks Oleg,
> > > > One question. I think it would be up to server implementation whether
> > to
> > > > take these parameters into account right?
> > > > Regards,
> > > > Murat
> > > >
> > > > On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski <
> ol...@apache.org>
> > > > wrote:
> > > >
> > > > > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> > > > > > Murat,
> > > > > >
> > > > > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan <
> mrbal...@gmail.com>
> > > > > wrote:
> > > > > > > I see. I think that also means that I cannot share the
> > > > > ClosableHttpClient
> > > > > > > instance among multiple threads as each client can refer to one
> > > > > connection
> > > > > > > manager instance.
> > > > > > >
> > > > > > > Can connectionreusestrategy be used so that the pooling
> > connection
> > > > > manager
> > > > > > > will always return a new connection regardless of the route
> > > provided?
> > > > > >
> > > > > > I did not think about that, guess you could use the
> > > > > NoConnectionReuseStrategy
> > > > > >
> > > > >
> > > > > That would be one option. Another option is to manually evict
> > > persistent
> > > > > connections from the pool after each transaction. Another option is
> > to
> > > > > set connection TTL (total time to live) to some very low value.
> > Another
> > > > > option is to simply use 'connection: close' request header.
> > > > >
> > > > > Oleg
> > > > >
> > > > > > - Bindul
> > > > > >
> > > > > > >
> > > > > > > Regards.
> > > > > > > Murat
> > > > > > >
> > > > > > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul <
> > > > > bindulbhow...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Murat,
> > > > > > >>
> > > > > > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan <
> > > mrbal...@gmail.com>
> > > > > wrote:
> > > > > > >> > Hi Bindul,
> > > > > > >> > Thanks for the answer.
> > > > > > >> > I was thinking that using a shared connection manager will
> > > > increase
> > > > > the
> > > > > > >> > performance. What will be the implications of reusing the
> same
> > > > > > >> > BasicHttpClientConnectionManager instance?
> > > > > > >>
> > > > > > >> If you see the documentation for the
> > > BasicHttpClientConnectionManag
> > > > er
> > > > > > >> [1], you will see that it only maintains one active
> connection.
> > If
> > > > you
> > > > > > >> share the the instance, your requests will be waiting for the
> > > > > > >> connection to be available and that will be your bottleneck.
> > > > > > >>
> > > > > > >> I would also recommend reading the connection management
> section
> > > of
> > > > > > >> the Http Client documentation [2]
> > > > > > >>
> > > > > > >> - Bindul
> > > > > > >>
> > > > > > >> [1] http://hc.apache.org/httpcomponents-client-ga/
> > > > > > >> httpclient/apidocs/org/apache/http/impl/conn/
> > > > > > >> BasicHttpClientConnectionManager.html
> > > > > > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> > > > > > >> tutorial/html/connmgmt.html
> > > > > > >>
> > > > > > >> > Regards,
> > > > > > >> > Murat
> > > > > > >> >
> > > > > > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> > > > > > >> bindulbhow...@gmail.com>
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> >> Murat,
> > > > > > >> >>
> > > > > > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan <
> > > > mrbal...@gmail.com
> > > > > >
> > > > > > >> wrote:
> > > > > > >> >> > Hi,
> > > > > > >> >> >
> > > > > > >> >> > We are using PoolingHttpClientConnectionManager to open
> up
> > > > > > >> connections
> > > > > > >> >> to
> > > > > > >> >> > multiple URL's in different threads (via different
> HttpGet
> > > > > objects).
> > > > > > >> >> >
> > > > > > >> >> > The only reason we are using the
> > > PoolingHttpClientConnectionMan
> > > > > ager
> > > > > > >> is
> > > > > > >> >> its'
> > > > > > >> >> > performance in multi-thread environments (as suggested by
> > the
> > > > > > >> >> > documentation).
> > > > > > >> >> >
> > > > > > >> >> > However, we are not interested in the actual "pooling"
> > > > > functionality.
> > > > > > >> >> > That's to say, we want to open 

Re: Controlling releaseConnection

[Oleg Kalnichevski]

On Tue, 2016-10-18 at 10:12 -0400, Pellerin, Clement wrote:
> I agree that code is correct. I never said there was a bug.
> I am asking how to override the behavior.
> We are porting our product from HttpClient 4.1 to 4.5.2
> and we need to preserve that feature because it is used by our customers.

Clement

I'll be happy to suggest a work-around but I am still unable to
understand what it is exactly you are trying to achieve by keeping a
connection for messages without a message body, which is quite uncommon
(status 204, status 304, response to HEAD, and that is it). 

What is exactly the point of doing so in th first place?

Oleg 


> It would be a shame to duplicate all of MainClientExec because
> of a lack of modularity in that class.
> 
> We tried to subclass the PoolingHttpClientConnectionManager
> but that does not work because the connection state is actually
> stored in the ConnectionHolder created directly in MainClientExec.execute().
> final ConnectionHolder connHolder = new ConnectionHolder(this.log, 
> this.connManager, managedConn);
> 
> Basically, I'm asking if the maintainers could consider a method like
>   protected boolean isEarlyRelease(HttpEntity entity) {
>   return entity == null || !entity.isStreaming();
>   }
> 
> Or a release strategy interface if this is a common requirement.
> I am also interested in any other work-around.
> 
> -Original Message-
> From: Shawn Heisey [mailto:apa...@elyograg.org] 
> Sent: Monday, October 17, 2016 9:24 PM
> To: HttpClient User Discussion
> Subject: Re: Controlling releaseConnection
> 
> On 10/17/2016 3:22 PM, Pellerin, Clement wrote:
> > Our customer needs to delay the release of the connection until the 
> > response is fully processed.
> > They want to turn off the early automatic release of the connection and do 
> > it manually later.
> >
> > This is the problematic code in MainClientExec
> > // check for entity, release connection if possible
> > final HttpEntity entity = response.getEntity();
> > if (entity == null || !entity.isStreaming()) {
> > // connection not needed and (assumed to be) in re-usable 
> > state
> > connHolder.releaseConnection();
> > return new HttpResponseProxy(response, null);
> > } else {
> > return new HttpResponseProxy(response, connHolder);
> > }
> 
> Mostly an end-user here, with no status to speak of in this project.  I do 
> have status on another Apache project that utilizes HttpClient, but I don't 
> know much about that part of the code.  I have written some HttpClient code 
> for a completely unrelated project of my own, but that code is VERY simple.
> 
> When I read the code above, what I see is this: It only releases the 
> connection if the entity is nonexistent (null) or the entity is NOT a type 
> that uses streaming.
> 
> I will fully admit that my experience with HttpClient is limited, but I think 
> the chance is very small that the HttpComponents committers have made a 
> mistake here.  I think this particular code has probably been discussed and 
> examined, then ultimately validated as correct.  Here's why I think they 
> didn't make a mistake:
> 
> If the entity object is null, then the response probably doesn't HAVE an 
> entity (response body), so it will be entirely self-contained, consisting of 
> headers only, and the connection doesn't have anything further to send.  If 
> the entity exists but doesn't utilize streaming, then I think it's likely 
> that the entity was received in its entirety and has been incorporated into 
> the response object already, and once again, the connection isn't needed.  If 
> my limited understanding of non-streaming entities is correct, they have the 
> potential to be very dangerous from a memory consumption perspective, and my 
> own usage of HttpClient (where I did not set anything related to the entity 
> type) suggests that streaming entities are used by default.
> 
> Restating in another way:  In the first situation that results in a released 
> connection, there's nothing to consume, you just need the response object 
> that you already have.  In the second situation, the entity you will consume 
> is probably already available within the response object and doesn't need the 
> connection.  The comment on the release call in the code quoted above implies 
> that this is how things work.
> 
> In these situations, why do you need the connection to stick around?  I think 
> it can't do anything else that's useful for that request.  I would imagine 
> that if the connection utilizes keepalive/pipelining, that it will typically 
> remain open after release and can be utilized again for a different request.
> 
> Someone with more direct knowledge of HttpClient's internal implementation 
> will need to confirm whether or not I'm correct in what I've written.  My 
> understanding could be wrong.
> 
> 

Re: Disabling pooling of PoolingConnectionManager

[Stefan Magnus Landrø]

You could do both.

>From my experience all serious http server implementations respect the
Connection: close header

2016-10-18 16:35 GMT+02:00 Murat Balkan :

> I checked with the RFC and it seems if provided, "connection: close" header
> is a MUST rather than SHOULD. So, it should not up to server
> implementation. But I find the TTL and Strategy approaches safer as we have
> some kind of control over them.
>
> On Tue, Oct 18, 2016 at 10:26 AM, Stefan Magnus Landrø <
> stefan.lan...@gmail.com> wrote:
>
> > Why would you think so?
> >
> > 2016-10-18 16:10 GMT+02:00 Murat Balkan :
> >
> > > Thanks Oleg,
> > > One question. I think it would be up to server implementation whether
> to
> > > take these parameters into account right?
> > > Regards,
> > > Murat
> > >
> > > On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski 
> > > wrote:
> > >
> > > > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> > > > > Murat,
> > > > >
> > > > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan 
> > > > wrote:
> > > > > > I see. I think that also means that I cannot share the
> > > > ClosableHttpClient
> > > > > > instance among multiple threads as each client can refer to one
> > > > connection
> > > > > > manager instance.
> > > > > >
> > > > > > Can connectionreusestrategy be used so that the pooling
> connection
> > > > manager
> > > > > > will always return a new connection regardless of the route
> > provided?
> > > > >
> > > > > I did not think about that, guess you could use the
> > > > NoConnectionReuseStrategy
> > > > >
> > > >
> > > > That would be one option. Another option is to manually evict
> > persistent
> > > > connections from the pool after each transaction. Another option is
> to
> > > > set connection TTL (total time to live) to some very low value.
> Another
> > > > option is to simply use 'connection: close' request header.
> > > >
> > > > Oleg
> > > >
> > > > > - Bindul
> > > > >
> > > > > >
> > > > > > Regards.
> > > > > > Murat
> > > > > >
> > > > > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul <
> > > > bindulbhow...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Murat,
> > > > > >>
> > > > > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan <
> > mrbal...@gmail.com>
> > > > wrote:
> > > > > >> > Hi Bindul,
> > > > > >> > Thanks for the answer.
> > > > > >> > I was thinking that using a shared connection manager will
> > > increase
> > > > the
> > > > > >> > performance. What will be the implications of reusing the same
> > > > > >> > BasicHttpClientConnectionManager instance?
> > > > > >>
> > > > > >> If you see the documentation for the
> > BasicHttpClientConnectionManag
> > > er
> > > > > >> [1], you will see that it only maintains one active connection.
> If
> > > you
> > > > > >> share the the instance, your requests will be waiting for the
> > > > > >> connection to be available and that will be your bottleneck.
> > > > > >>
> > > > > >> I would also recommend reading the connection management section
> > of
> > > > > >> the Http Client documentation [2]
> > > > > >>
> > > > > >> - Bindul
> > > > > >>
> > > > > >> [1] http://hc.apache.org/httpcomponents-client-ga/
> > > > > >> httpclient/apidocs/org/apache/http/impl/conn/
> > > > > >> BasicHttpClientConnectionManager.html
> > > > > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> > > > > >> tutorial/html/connmgmt.html
> > > > > >>
> > > > > >> > Regards,
> > > > > >> > Murat
> > > > > >> >
> > > > > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> > > > > >> bindulbhow...@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Murat,
> > > > > >> >>
> > > > > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan <
> > > mrbal...@gmail.com
> > > > >
> > > > > >> wrote:
> > > > > >> >> > Hi,
> > > > > >> >> >
> > > > > >> >> > We are using PoolingHttpClientConnectionManager to open up
> > > > > >> connections
> > > > > >> >> to
> > > > > >> >> > multiple URL's in different threads (via different HttpGet
> > > > objects).
> > > > > >> >> >
> > > > > >> >> > The only reason we are using the
> > PoolingHttpClientConnectionMan
> > > > ager
> > > > > >> is
> > > > > >> >> its'
> > > > > >> >> > performance in multi-thread environments (as suggested by
> the
> > > > > >> >> > documentation).
> > > > > >> >> >
> > > > > >> >> > However, we are not interested in the actual "pooling"
> > > > functionality.
> > > > > >> >> > That's to say, we want to open up a brand new connection
> even
> > > if
> > > > the
> > > > > >> >> route
> > > > > >> >> > is the same.
> > > > > >> >>
> > > > > >> >> The performance enhancements you achieve from
> > > > > >> >> PoolingHttpClientConnectionManager are due to its connection
> > > > pooling
> > > > > >> >> feature, that saves you to cost of establishing the
> connection
> > > when
> > > > > >> >> another request goes to the same route.
> > > > > >> >>
> > > > > >> >> >
> > > > > >> >> > How 

Re: Disabling pooling of PoolingConnectionManager

[Murat Balkan]

I checked with the RFC and it seems if provided, "connection: close" header
is a MUST rather than SHOULD. So, it should not up to server
implementation. But I find the TTL and Strategy approaches safer as we have
some kind of control over them.

On Tue, Oct 18, 2016 at 10:26 AM, Stefan Magnus Landrø <
stefan.lan...@gmail.com> wrote:

> Why would you think so?
>
> 2016-10-18 16:10 GMT+02:00 Murat Balkan :
>
> > Thanks Oleg,
> > One question. I think it would be up to server implementation whether to
> > take these parameters into account right?
> > Regards,
> > Murat
> >
> > On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski 
> > wrote:
> >
> > > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> > > > Murat,
> > > >
> > > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan 
> > > wrote:
> > > > > I see. I think that also means that I cannot share the
> > > ClosableHttpClient
> > > > > instance among multiple threads as each client can refer to one
> > > connection
> > > > > manager instance.
> > > > >
> > > > > Can connectionreusestrategy be used so that the pooling connection
> > > manager
> > > > > will always return a new connection regardless of the route
> provided?
> > > >
> > > > I did not think about that, guess you could use the
> > > NoConnectionReuseStrategy
> > > >
> > >
> > > That would be one option. Another option is to manually evict
> persistent
> > > connections from the pool after each transaction. Another option is to
> > > set connection TTL (total time to live) to some very low value. Another
> > > option is to simply use 'connection: close' request header.
> > >
> > > Oleg
> > >
> > > > - Bindul
> > > >
> > > > >
> > > > > Regards.
> > > > > Murat
> > > > >
> > > > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul <
> > > bindulbhow...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Murat,
> > > > >>
> > > > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan <
> mrbal...@gmail.com>
> > > wrote:
> > > > >> > Hi Bindul,
> > > > >> > Thanks for the answer.
> > > > >> > I was thinking that using a shared connection manager will
> > increase
> > > the
> > > > >> > performance. What will be the implications of reusing the same
> > > > >> > BasicHttpClientConnectionManager instance?
> > > > >>
> > > > >> If you see the documentation for the
> BasicHttpClientConnectionManag
> > er
> > > > >> [1], you will see that it only maintains one active connection. If
> > you
> > > > >> share the the instance, your requests will be waiting for the
> > > > >> connection to be available and that will be your bottleneck.
> > > > >>
> > > > >> I would also recommend reading the connection management section
> of
> > > > >> the Http Client documentation [2]
> > > > >>
> > > > >> - Bindul
> > > > >>
> > > > >> [1] http://hc.apache.org/httpcomponents-client-ga/
> > > > >> httpclient/apidocs/org/apache/http/impl/conn/
> > > > >> BasicHttpClientConnectionManager.html
> > > > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> > > > >> tutorial/html/connmgmt.html
> > > > >>
> > > > >> > Regards,
> > > > >> > Murat
> > > > >> >
> > > > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> > > > >> bindulbhow...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Murat,
> > > > >> >>
> > > > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan <
> > mrbal...@gmail.com
> > > >
> > > > >> wrote:
> > > > >> >> > Hi,
> > > > >> >> >
> > > > >> >> > We are using PoolingHttpClientConnectionManager to open up
> > > > >> connections
> > > > >> >> to
> > > > >> >> > multiple URL's in different threads (via different HttpGet
> > > objects).
> > > > >> >> >
> > > > >> >> > The only reason we are using the
> PoolingHttpClientConnectionMan
> > > ager
> > > > >> is
> > > > >> >> its'
> > > > >> >> > performance in multi-thread environments (as suggested by the
> > > > >> >> > documentation).
> > > > >> >> >
> > > > >> >> > However, we are not interested in the actual "pooling"
> > > functionality.
> > > > >> >> > That's to say, we want to open up a brand new connection even
> > if
> > > the
> > > > >> >> route
> > > > >> >> > is the same.
> > > > >> >>
> > > > >> >> The performance enhancements you achieve from
> > > > >> >> PoolingHttpClientConnectionManager are due to its connection
> > > pooling
> > > > >> >> feature, that saves you to cost of establishing the connection
> > when
> > > > >> >> another request goes to the same route.
> > > > >> >>
> > > > >> >> >
> > > > >> >> > How can we achieve this? We tried to set maxPerroute to 1 but
> > it
> > > > >> seems it
> > > > >> >> > is not the correct way.
> > > > >> >>
> > > > >> >> I have not tested, but setting maxPerRoute to 1 would degrade
> > > > >> >> performance for you as you will have a number of Http clients
> > > waiting
> > > > >> >> for the single connection.
> > > > >> >>
> > > > >> >> If you do not want to use pooled connections, you can use
> > > > >> >> 

Re: Disabling pooling of PoolingConnectionManager

[Stefan Magnus Landrø]

Why would you think so?

2016-10-18 16:10 GMT+02:00 Murat Balkan :

> Thanks Oleg,
> One question. I think it would be up to server implementation whether to
> take these parameters into account right?
> Regards,
> Murat
>
> On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski 
> wrote:
>
> > On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> > > Murat,
> > >
> > > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan 
> > wrote:
> > > > I see. I think that also means that I cannot share the
> > ClosableHttpClient
> > > > instance among multiple threads as each client can refer to one
> > connection
> > > > manager instance.
> > > >
> > > > Can connectionreusestrategy be used so that the pooling connection
> > manager
> > > > will always return a new connection regardless of the route provided?
> > >
> > > I did not think about that, guess you could use the
> > NoConnectionReuseStrategy
> > >
> >
> > That would be one option. Another option is to manually evict persistent
> > connections from the pool after each transaction. Another option is to
> > set connection TTL (total time to live) to some very low value. Another
> > option is to simply use 'connection: close' request header.
> >
> > Oleg
> >
> > > - Bindul
> > >
> > > >
> > > > Regards.
> > > > Murat
> > > >
> > > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul <
> > bindulbhow...@gmail.com>
> > > > wrote:
> > > >
> > > >> Murat,
> > > >>
> > > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan 
> > wrote:
> > > >> > Hi Bindul,
> > > >> > Thanks for the answer.
> > > >> > I was thinking that using a shared connection manager will
> increase
> > the
> > > >> > performance. What will be the implications of reusing the same
> > > >> > BasicHttpClientConnectionManager instance?
> > > >>
> > > >> If you see the documentation for the BasicHttpClientConnectionManag
> er
> > > >> [1], you will see that it only maintains one active connection. If
> you
> > > >> share the the instance, your requests will be waiting for the
> > > >> connection to be available and that will be your bottleneck.
> > > >>
> > > >> I would also recommend reading the connection management section of
> > > >> the Http Client documentation [2]
> > > >>
> > > >> - Bindul
> > > >>
> > > >> [1] http://hc.apache.org/httpcomponents-client-ga/
> > > >> httpclient/apidocs/org/apache/http/impl/conn/
> > > >> BasicHttpClientConnectionManager.html
> > > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> > > >> tutorial/html/connmgmt.html
> > > >>
> > > >> > Regards,
> > > >> > Murat
> > > >> >
> > > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> > > >> bindulbhow...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >> Murat,
> > > >> >>
> > > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan <
> mrbal...@gmail.com
> > >
> > > >> wrote:
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > We are using PoolingHttpClientConnectionManager to open up
> > > >> connections
> > > >> >> to
> > > >> >> > multiple URL's in different threads (via different HttpGet
> > objects).
> > > >> >> >
> > > >> >> > The only reason we are using the PoolingHttpClientConnectionMan
> > ager
> > > >> is
> > > >> >> its'
> > > >> >> > performance in multi-thread environments (as suggested by the
> > > >> >> > documentation).
> > > >> >> >
> > > >> >> > However, we are not interested in the actual "pooling"
> > functionality.
> > > >> >> > That's to say, we want to open up a brand new connection even
> if
> > the
> > > >> >> route
> > > >> >> > is the same.
> > > >> >>
> > > >> >> The performance enhancements you achieve from
> > > >> >> PoolingHttpClientConnectionManager are due to its connection
> > pooling
> > > >> >> feature, that saves you to cost of establishing the connection
> when
> > > >> >> another request goes to the same route.
> > > >> >>
> > > >> >> >
> > > >> >> > How can we achieve this? We tried to set maxPerroute to 1 but
> it
> > > >> seems it
> > > >> >> > is not the correct way.
> > > >> >>
> > > >> >> I have not tested, but setting maxPerRoute to 1 would degrade
> > > >> >> performance for you as you will have a number of Http clients
> > waiting
> > > >> >> for the single connection.
> > > >> >>
> > > >> >> If you do not want to use pooled connections, you can use
> > > >> >> BasicHttpClientConnectionManager and not share it.
> > > >> >>
> > > >> >> >
> > > >> >> > Regards,
> > > >> >> > Murat
> > > >> >>
> > > >> >> 
> > -
> > > >> >> To unsubscribe, e-mail: httpclient-users-unsubscribe@
> hc.apache.org
> > > >> >> For additional commands, e-mail: httpclient-users-help@hc.
> > apache.org
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Murat Balkan
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > 

RE: Controlling releaseConnection

[Pellerin, Clement]

I agree that code is correct. I never said there was a bug.
I am asking how to override the behavior.
We are porting our product from HttpClient 4.1 to 4.5.2
and we need to preserve that feature because it is used by our customers.
It would be a shame to duplicate all of MainClientExec because
of a lack of modularity in that class.

We tried to subclass the PoolingHttpClientConnectionManager
but that does not work because the connection state is actually
stored in the ConnectionHolder created directly in MainClientExec.execute().
final ConnectionHolder connHolder = new ConnectionHolder(this.log, 
this.connManager, managedConn);

Basically, I'm asking if the maintainers could consider a method like
protected boolean isEarlyRelease(HttpEntity entity) {
return entity == null || !entity.isStreaming();
}

Or a release strategy interface if this is a common requirement.
I am also interested in any other work-around.

-Original Message-
From: Shawn Heisey [mailto:apa...@elyograg.org] 
Sent: Monday, October 17, 2016 9:24 PM
To: HttpClient User Discussion
Subject: Re: Controlling releaseConnection

On 10/17/2016 3:22 PM, Pellerin, Clement wrote:
> Our customer needs to delay the release of the connection until the response 
> is fully processed.
> They want to turn off the early automatic release of the connection and do it 
> manually later.
>
> This is the problematic code in MainClientExec
> // check for entity, release connection if possible
> final HttpEntity entity = response.getEntity();
> if (entity == null || !entity.isStreaming()) {
> // connection not needed and (assumed to be) in re-usable 
> state
> connHolder.releaseConnection();
> return new HttpResponseProxy(response, null);
> } else {
> return new HttpResponseProxy(response, connHolder);
> }

Mostly an end-user here, with no status to speak of in this project.  I do have 
status on another Apache project that utilizes HttpClient, but I don't know 
much about that part of the code.  I have written some HttpClient code for a 
completely unrelated project of my own, but that code is VERY simple.

When I read the code above, what I see is this: It only releases the connection 
if the entity is nonexistent (null) or the entity is NOT a type that uses 
streaming.

I will fully admit that my experience with HttpClient is limited, but I think 
the chance is very small that the HttpComponents committers have made a mistake 
here.  I think this particular code has probably been discussed and examined, 
then ultimately validated as correct.  Here's why I think they didn't make a 
mistake:

If the entity object is null, then the response probably doesn't HAVE an entity 
(response body), so it will be entirely self-contained, consisting of headers 
only, and the connection doesn't have anything further to send.  If the entity 
exists but doesn't utilize streaming, then I think it's likely that the entity 
was received in its entirety and has been incorporated into the response object 
already, and once again, the connection isn't needed.  If my limited 
understanding of non-streaming entities is correct, they have the potential to 
be very dangerous from a memory consumption perspective, and my own usage of 
HttpClient (where I did not set anything related to the entity type) suggests 
that streaming entities are used by default.

Restating in another way:  In the first situation that results in a released 
connection, there's nothing to consume, you just need the response object that 
you already have.  In the second situation, the entity you will consume is 
probably already available within the response object and doesn't need the 
connection.  The comment on the release call in the code quoted above implies 
that this is how things work.

In these situations, why do you need the connection to stick around?  I think 
it can't do anything else that's useful for that request.  I would imagine that 
if the connection utilizes keepalive/pipelining, that it will typically remain 
open after release and can be utilized again for a different request.

Someone with more direct knowledge of HttpClient's internal implementation will 
need to confirm whether or not I'm correct in what I've written.  My 
understanding could be wrong.

Thanks,
Shawn


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

Re: Disabling pooling of PoolingConnectionManager

[Murat Balkan]

Thanks Oleg,
One question. I think it would be up to server implementation whether to
take these parameters into account right?
Regards,
Murat

On Tue, Oct 18, 2016 at 10:06 AM, Oleg Kalnichevski 
wrote:

> On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> > Murat,
> >
> > On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan 
> wrote:
> > > I see. I think that also means that I cannot share the
> ClosableHttpClient
> > > instance among multiple threads as each client can refer to one
> connection
> > > manager instance.
> > >
> > > Can connectionreusestrategy be used so that the pooling connection
> manager
> > > will always return a new connection regardless of the route provided?
> >
> > I did not think about that, guess you could use the
> NoConnectionReuseStrategy
> >
>
> That would be one option. Another option is to manually evict persistent
> connections from the pool after each transaction. Another option is to
> set connection TTL (total time to live) to some very low value. Another
> option is to simply use 'connection: close' request header.
>
> Oleg
>
> > - Bindul
> >
> > >
> > > Regards.
> > > Murat
> > >
> > > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul <
> bindulbhow...@gmail.com>
> > > wrote:
> > >
> > >> Murat,
> > >>
> > >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan 
> wrote:
> > >> > Hi Bindul,
> > >> > Thanks for the answer.
> > >> > I was thinking that using a shared connection manager will increase
> the
> > >> > performance. What will be the implications of reusing the same
> > >> > BasicHttpClientConnectionManager instance?
> > >>
> > >> If you see the documentation for the BasicHttpClientConnectionManager
> > >> [1], you will see that it only maintains one active connection. If you
> > >> share the the instance, your requests will be waiting for the
> > >> connection to be available and that will be your bottleneck.
> > >>
> > >> I would also recommend reading the connection management section of
> > >> the Http Client documentation [2]
> > >>
> > >> - Bindul
> > >>
> > >> [1] http://hc.apache.org/httpcomponents-client-ga/
> > >> httpclient/apidocs/org/apache/http/impl/conn/
> > >> BasicHttpClientConnectionManager.html
> > >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> > >> tutorial/html/connmgmt.html
> > >>
> > >> > Regards,
> > >> > Murat
> > >> >
> > >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> > >> bindulbhow...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Murat,
> > >> >>
> > >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan  >
> > >> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > We are using PoolingHttpClientConnectionManager to open up
> > >> connections
> > >> >> to
> > >> >> > multiple URL's in different threads (via different HttpGet
> objects).
> > >> >> >
> > >> >> > The only reason we are using the PoolingHttpClientConnectionMan
> ager
> > >> is
> > >> >> its'
> > >> >> > performance in multi-thread environments (as suggested by the
> > >> >> > documentation).
> > >> >> >
> > >> >> > However, we are not interested in the actual "pooling"
> functionality.
> > >> >> > That's to say, we want to open up a brand new connection even if
> the
> > >> >> route
> > >> >> > is the same.
> > >> >>
> > >> >> The performance enhancements you achieve from
> > >> >> PoolingHttpClientConnectionManager are due to its connection
> pooling
> > >> >> feature, that saves you to cost of establishing the connection when
> > >> >> another request goes to the same route.
> > >> >>
> > >> >> >
> > >> >> > How can we achieve this? We tried to set maxPerroute to 1 but it
> > >> seems it
> > >> >> > is not the correct way.
> > >> >>
> > >> >> I have not tested, but setting maxPerRoute to 1 would degrade
> > >> >> performance for you as you will have a number of Http clients
> waiting
> > >> >> for the single connection.
> > >> >>
> > >> >> If you do not want to use pooled connections, you can use
> > >> >> BasicHttpClientConnectionManager and not share it.
> > >> >>
> > >> >> >
> > >> >> > Regards,
> > >> >> > Murat
> > >> >>
> > >> >> 
> -
> > >> >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > >> >> For additional commands, e-mail: httpclient-users-help@hc.
> apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > Murat Balkan
> > >>
> > >> -
> > >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Murat Balkan
> >
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >
>
>
>
> 

Re: Disabling pooling of PoolingConnectionManager

[Oleg Kalnichevski]

On Mon, 2016-10-17 at 22:06 -0600, Bhowmik, Bindul wrote:
> Murat,
> 
> On Mon, Oct 17, 2016 at 8:11 PM, Murat Balkan  wrote:
> > I see. I think that also means that I cannot share the ClosableHttpClient
> > instance among multiple threads as each client can refer to one connection
> > manager instance.
> >
> > Can connectionreusestrategy be used so that the pooling connection manager
> > will always return a new connection regardless of the route provided?
> 
> I did not think about that, guess you could use the NoConnectionReuseStrategy
> 

That would be one option. Another option is to manually evict persistent
connections from the pool after each transaction. Another option is to
set connection TTL (total time to live) to some very low value. Another
option is to simply use 'connection: close' request header.

Oleg  

> - Bindul
> 
> >
> > Regards.
> > Murat
> >
> > On Mon, Oct 17, 2016 at 5:05 PM, Bhowmik, Bindul 
> > wrote:
> >
> >> Murat,
> >>
> >> On Mon, Oct 17, 2016 at 12:58 PM, Murat Balkan  wrote:
> >> > Hi Bindul,
> >> > Thanks for the answer.
> >> > I was thinking that using a shared connection manager will increase the
> >> > performance. What will be the implications of reusing the same
> >> > BasicHttpClientConnectionManager instance?
> >>
> >> If you see the documentation for the BasicHttpClientConnectionManager
> >> [1], you will see that it only maintains one active connection. If you
> >> share the the instance, your requests will be waiting for the
> >> connection to be available and that will be your bottleneck.
> >>
> >> I would also recommend reading the connection management section of
> >> the Http Client documentation [2]
> >>
> >> - Bindul
> >>
> >> [1] http://hc.apache.org/httpcomponents-client-ga/
> >> httpclient/apidocs/org/apache/http/impl/conn/
> >> BasicHttpClientConnectionManager.html
> >> [2] http://hc.apache.org/httpcomponents-client-4.5.x/
> >> tutorial/html/connmgmt.html
> >>
> >> > Regards,
> >> > Murat
> >> >
> >> > On Mon, Oct 17, 2016 at 2:31 PM, Bhowmik, Bindul <
> >> bindulbhow...@gmail.com>
> >> > wrote:
> >> >
> >> >> Murat,
> >> >>
> >> >> On Mon, Oct 17, 2016 at 11:12 AM, Murat Balkan 
> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We are using PoolingHttpClientConnectionManager to open up
> >> connections
> >> >> to
> >> >> > multiple URL's in different threads (via different HttpGet objects).
> >> >> >
> >> >> > The only reason we are using the PoolingHttpClientConnectionManager
> >> is
> >> >> its'
> >> >> > performance in multi-thread environments (as suggested by the
> >> >> > documentation).
> >> >> >
> >> >> > However, we are not interested in the actual "pooling" functionality.
> >> >> > That's to say, we want to open up a brand new connection even if the
> >> >> route
> >> >> > is the same.
> >> >>
> >> >> The performance enhancements you achieve from
> >> >> PoolingHttpClientConnectionManager are due to its connection pooling
> >> >> feature, that saves you to cost of establishing the connection when
> >> >> another request goes to the same route.
> >> >>
> >> >> >
> >> >> > How can we achieve this? We tried to set maxPerroute to 1 but it
> >> seems it
> >> >> > is not the correct way.
> >> >>
> >> >> I have not tested, but setting maxPerRoute to 1 would degrade
> >> >> performance for you as you will have a number of Http clients waiting
> >> >> for the single connection.
> >> >>
> >> >> If you do not want to use pooled connections, you can use
> >> >> BasicHttpClientConnectionManager and not share it.
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Murat
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> >> >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Murat Balkan
> >>
> >> -
> >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >>
> >>
> >
> >
> > --
> > Murat Balkan
> 
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 



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

Re: AW: Controlling releaseConnection

[Oleg Kalnichevski]

On Tue, 2016-10-18 at 01:46 +0200, e...@zusammenkunft.net wrote:
> Hello,
> 
> Can younspecify why you need to delay it? Do wou want to make some kind of 
> rate limit with this or optimize pipelining?
> 
> Gruss
> Bernd

I am not quite sure I understand the problem. HttpClient releases
connection back to the pool only when done reading content from it. Why
would one want to hold onto the connection once the response message has
been fully consumed? Am I missing something?

Oleg


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