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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
