hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25372] - auto close idle connections
Date Mon, 12 Apr 2004 15:15:32 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=25372>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25372

auto close idle connections





------- Additional Comments From olegk@apache.org  2004-04-12 15:15 -------
Mike,
You have a perfectly valid solution to the problem, so feel free to dismiss my
ideas because they are based completely on personal preferences rather than on
any objective good programming practices. 

This is how I would go about this problem: 

* What I do not quite like about the current implementation is that each
connection manager needs to explicitly check connections in and out with the
idle connection handler (as a result the idle connection handler is coupled with
the HttpConnection class, the fact I tend to dislike out of my purely personal
feelings)
* At the same time there's no API that enforces a connection manager to respect
this implicit contract. There's an assumption that a well behaving connection
manager would do so, which custom connection managers, however, may choose to ignore
* In my opinion HttpConnectionManager implementing classes appear better
equipped to keep track of connection properties (including how long a connection
stays idle and all sorts of statistical data: for instance, active time versus
idle time)
* I would add a new method to the HttpConnectionManager class:
HttpConnectionManager#closeIdleConnections(int);
* I would rather have HttpConnectionManager classes keep track of connections
idle time
* Users would not need to always have a dedicated thread watching over
connections. Some of them (for instance, I (do I qualify as a user? ;-)) would
rather call closeIdleConnections once in a while from the main thread 
* I would have an optional idle connection handler class for those who need it.
It would maintain a list of connection managers it is watching over, run a low
priority thread, and call on connection managers to close their idle connections
without knowing a dang thing about what a connection is
* One may have multiple idle connection handlers watching over multiple
connection managers without causing to much problems to one another as their
coupling is very loose. There's no (should be no) harm in calling
closeIdleConnections multiple time from multiple threads (apart from the obvious
performance hit)

I do not know if that makes any sense. If it does not, I certainly will not
object checking in the proposed patch

Oleg

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


Mime
View raw message