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