> Also, looking it over, it looks like the ThrottledInputStream will block
The bandwidth limiting bits will no longer block one thread for too long. Max 4 seconds, even if no bandwidth. > locking ThrottledInputStream is implemented, it MUST have some way of > obeying tcpConnection.setSoTimeout(). The throttling is just a filter on the underlying socket so any socket operations will be respected. > When bandwidth limiting kicked in > on hawk, it managed to grow by 100 threads in 10 minutes because it kept > accepting connections but was not able to destroy any (presumably > because they were all locked waiting for bandwidth.) New throttled stream creation now competes for bandwidth along with use so the stream creation thread should no longer outpace existing threads. Also no throttled stream should block for more than 4 seconds at a time. > I think that a bandwidth limiter has to play nicely with a limit on the > number of open connections somehow - we cannot just keep opening > connections and spreading the water thinner and thinner. Possibly the bandwidth code could decrement the maxConnections parameter when limiting starts. Or the creation thread could time connection creation times and decrement maxConnections when these times started to slow. > Also, why is ThrottledInputStream only wrapped around Input on incoming > connections? My error. Will fix later. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
