Hi Roland,
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.
I agree. The key issue is making sure interrupts don't break the connection manager. I did some more digging about our options and will post my thoughts on JIRA in a few minutes.
ConnectionPoolInterruptedException extends ConnectionPoolTimeoutException? Sun has an InterruptedIOException for exception mapping purposes.
That might be a good option.
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.
My preference would be to not break the API for something relatively uncommon like this. In my opinion, our choices would be to throw a runtime exception or just continue to wait.
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.
I agree moving away from interrupt brings up a whole host of potential issues. I will detail this in JIRA. Thanks, Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
