hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject [HttpConn] another status update
Date Sun, 18 Feb 2007 19:23:51 GMT
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

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

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 :-)


[3] https://issues.apache.org/jira/browse/HTTPCLIENT-589

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message