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-21 22:55 ------- Hi Moh, > Sorry about that, I missed the javadoc at the top. There is, however, one > downside to doing the synchronization at a higher level: the lock is held while > idle connections are being closed. In other words, no new connections can be > made, no connections can be checked out, etc while we're trying to close off old > connections. Is socket.close() a fast operation or can it take some time (tens > of milliseconds)? If it's slow, we may have to think about this carefully. This is true, but I don't think there is much we can do about it. We need to ensure synchronized access to the connections, and I think we will end up blocking one way or another. The upside is that closing idle connections should not happen happen terribly often. My feeling is that this will not be a major performance problem. Please let me know if your experience proves otherwise. > But all references to it are not lost: my main thread holds onto the connection > manager, which holds onto the idle connection handler. Consider for example an > HTTP proxy, implemented using HttpClient: the usage pattern requires lots of > arbitrary connections to many different hosts. If nobody calls > closeIdleConnections, the tree structure will not get cleaned out and the > chances of a http connection being reused are slim (actually, they're high for > short bursts, but low over the long run). Am I missing something? I guess I'm not sure how this is different from the current behavior. The connection managers already hold references to all connections that they own. The idle connection handler just adds a second reference. These changes do not effect the connection life-cycle they just allow for tracking idle connections. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]