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
