On Sun, 2007-02-18 at 20:23 +0100, Roland Weber wrote: > Hi all, > > I've hacked up plenty of connection release code in HttpConn, > plus some use of that code in HttpClient and examples. Since > I was a little bit confused myself when writing that code, > I'll give you a quick intro in case you want to have a look. > There are three levels on which a connection can be released: > > (1) Connection Management level > The connection manager has a releaseConnection method that > expects the connection as argument. The connection itself > also has a releaseConnection method and will call back to > it's connection manager if that is called. Actually there > are two methods: > releaseConnection - gracefully > abortConnection - enforces shutdown, no connection re-use > > (2) Entity level > The new BasicManagedEntity keeps a reference to the connection > that should be released. There are three methods: > consumeContent - gracefully > releaseConnection - gracefully > abortConnection - enforces shutdown, no connection re-use > The entity also installs a level 3 notification handler. > > (3) Stream level > EofSensorInputStream replaces AutoCloseInputStream. There > are three methods: > close - gracefully > releaseConnection - gracefully > abortConnection - enforces shutdown, no connection re-use > Actual handling is typically delegated to the watcher. > > > I know it sounds tricky. It is. But I don't think we could > or should drop any of those levels or methods.
This seems reasonable to me, at least as far as the high level design is concerned. > The two > methods available on all three levels are defined in > ConnectionReleaseTrigger to facilitate instanceof checks. > The additional methods on some levels are required by the > interfaces implemented. > A release option on the entity level should be available > since HttpEntity.getContent() will return the stream only > once. If a method like EntityUtils.toString(HttpEntity) > accesses the stream and then fails before reading to the > end, level 3 can no longer be used to release the connection. > Dragging level 1 information through your application is > the situation which we have in HttpClient 3, and we've had > requests to drop that requirement since years ago. > It is hard to determine on one level whether the connection > has already been released on another level. The manager is > therefore required to tolerate multiple release of a single > connection. > > Another detail I introduced is a flag in the connection > that tells the manager whether it is reusable. That's > meant for tracking the communication states as mentioned > in [1] and [2], but it also came in handy for implementing > abortConnection(). > > I don't consider that another milestone, but I'm closing > in on one. At the very least, I want to add support for > a connection re-use strategy in the request director. > There will be a little twitch to that one: instead of > remembering the strategy and arguments required to call it > until the connection is released, I'd like to evaluate > the strategy directly after the response header is received > and only remember the boolean result. That will go a long > way towards addressing HTTPCLIENT-589. It shouldn't make a > difference to the strategy, unless that depends on trailers. > Has anybody ever seen trailers being used in the wild? > I have not. I am in favor of just ignoring trailers in HttpClient. Trailers are fully supported in HttpCore, but they appear to be of no use what so ever for HttpClient. > Once that is addressed, the question will be whether I > should implement a SimpleClientConnectionManager before > or after writing test cases for ThreadSafeClientConnManager > and the rest of HttpConn. What do you think? I think you should bring your work on HttpConn to some kind of logical closure and then start working on adding test coverage. > Of course I have plenty of ideas for HttpClient, but I > feel it makes more sense to stabilize HttpConn quickly. > Test cases are a prerequisite for cleaning up TSCCM. > > I'm signing off for today... Snooker is on :-) > First things first ;-) Cheers Oleg > cheers, > Roland > > [1] > http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/[EMAIL > PROTECTED] > [2] > http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/[EMAIL > PROTECTED] > [3] https://issues.apache.org/jira/browse/HTTPCLIENT-589 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
