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. 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? 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? 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 :-) 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]
