Hi Mike, > My question is if interrupting a waiting thread outside of the connection > manager > is something we want to support.
We can't prevent it, so we should at least make sure that it doesn't screw up our internal data structures. Whether we'll keep the thread waiting in a loop or whether we'll cancel waiting is up for debate. I prefer the cancelling. > If we did, would we just throw a ConnectionPoolTimeoutException when it > occurs? ConnectionPoolInterruptedException extends ConnectionPoolTimeoutException? Sun has an InterruptedIOException for exception mapping purposes. > This would seem to break the contract of doGetConnection. I'm not sure how we > will handle HttpConnection getConnection(HostConfiguration hostConfiguration) > without an API change. The API change will not affect users in cases where the current code works correctly. In cases where the current code runs into a bug, I guess throwing an exception is the lesser evil. > Assuming we did want to change this, we would need to > [snipped some scary things] I'd rather stick with the interrupt technique than switch to wait/notify in 3.1. The code will undergo a major revamp for 4.0 anyway, that is the occasion to change such fundamental behavior. The current implementation has worked well so far. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
