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 

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 

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.


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

Reply via email to