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.
Hi Roland, I started reviewing the latest HttpConn and HttpClient changes. I tend to start the review process by taking a look at the examples first just to get a feel about the API and then gradually work my way deeper into the implementation classes. I have a few immediate questions (1) I tend to dislike static helper methods in examples, because they disrupt the linear control flow and make code more difficult to read IMO. Samples do not have to be very code efficient. May I inline all private static helper methods in the samples? (2) May I change the samples to make use of HttpRequestExecutor instead writing and reading stuff directly to and from the connection objects? I think we ought not encourage the direct use of connection objects by the end users. (3) I would like to add logging decorators for HttpDataReceiver and HttpDataTransmitter interfaces, so we could have the convenience of wire logging, which I find very useful when developing new stuff. Cheers Oleg > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
