hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "ConnectionManagementDesign" by RolandWeber
Date Sun, 28 Jan 2007 07:31:32 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change
notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign

The comment on the change is:
added thoughts on releasing connections

------------------------------------------------------------------------------
  
  Modifiable objects for authentication states have implications if used in a non-modifiable
route representation. This would need to be documented carefully, but the problem is not different
from using modifiable objects as lookup keys.
  
+ 
+ == Connection Release ==
+ 
+ Connections need to be released to the manager. This should be done in a timely fashion
as soon as they are no longer needed.
+ A connection is no longer needed when the response entity (if any) will not be read from
anymore.
+ That can happen because it is read or buffered completely, because the application doesn't
need to read the rest, or because of an error that prevents the rest of the entity from being
read.
+ [[BR]]
+ An application can release the connection explicitly, but that puts the burden of a timely
release on the application.
+ It would be preferable to auto-release connections in certain situations, for example if
there is no entity, if the entity is read completely, or if the stream for reading the entity
is closed.
+ In error situations that are deemed non-recoverable, a stream could also auto-release the
connection.
+ [[BR]]
+ Tricky to detect are situations where applications just don't make use of the entity, without
an API call to indicate that.
+ If the reference to the entity is lost, garbage collection of the entity or connection can
be detected.
+ Cases where the application keeps a reference could be dealt with by a timeout mechanism,
where the application is given a maximum handling time or idle time until the connection is
auto-released.
+ [[BR]]
+ See also this [http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
discussion] in the mail archive.
+ 
+ A related problem is to decide whether the released connection is in a state that allows
keep-alive or not.
+ See this [http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
discussion] in the mail archive.
+ If the connection state allows for keep-alive, applying a keep-alive strategy is the next
step.
+ 

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


Mime
View raw message