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-09 03:05 ------- > Somehow I can't help thinking that coupling IdleConnectionHandler with > HttpConnection is not not > ideal. What if one sets a ridiculously high idle timeout value? Connections > would be piling up in the IdleConnectionHandler unnecessarily. Someone could certainly set an unwise timeout value, but that is true for many HttpClient settings. We should ensure that the default value is good, and then rely on people to not shooting themselves in the foot. I don't see the danger of having connections pile up. It may be somewhat unelegant, but it at least ensures that connections are eventually cleaned up. The current alternative is to just let the connections get GCed. This method does not guarantee that the sockets are closed. As far as coupling IdleConnectionHandler with HttpConnection, I'm not sure how else to do it. What would you suggest? > I would rather see IdleConnectionHandler monitor connections of just one > connection manager, and would rather have the IdleConnectionHandler stay alive > as long as the connection manager itself stays alive. I understand your > intention was to have only one dedicated thread watching over all active > connections in order to conserve resources. I personally would rather prefer a > little less resource efficient but slightly more elegant solution. Besides, do > not we encourage people to have just one HttpClient instance with just one > connection manager per application, do we? One IdleConnectionHandler per connection manager can be done with the current system. Since the idle handler is just a param, a different one can be used per connection manager. I agree that having just one idle handler for all connection managers may not be good, I also think the reverse is no better. My intention was to have a sane default behavior that supports customization. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
