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. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org