It is an odd problem. Not quite a dead-lock in the traditional sense. One thread is waiting on the other, and the other is waiting for the garbage collector. It just so happens that the garbage collector will never kick in, because the first thread happens to be the AWT Event thread, so the user cannot interact with the application any further, thus no objects get allocated, and there is no reason to garbage collect. To oversimplify, Thread A depends on Thread B depends on Thread C depends (indirectly) on Thread A.
Ortwin Glück wrote:
It's not clear to me how this can be a dead lock.
Eric Johnson wrote:
MultiThreadedHttpConnectionManager.doGetConnection() - line 302, which reads "connectionPool.wait(timeToWait)",
This is a limited wait. Not infinite. Oleg, do we ensure that timeToWait>0 somehow?
You seem to be echoing one of my recommendations - the code should disallow passing zero here. It doesn't currently, but I think it should, since the timeout value it is using is the one associated internally with socket connection timeouts, which if not set essentially defaults to the lower bound of what all the intervening routers allow, whereas this particular wait has no limit besides what we pass.
and the other thread at
MultiThreadedHttpConnectionManager.ReferenceQueuedThread.run(), line 665, which reads "Reference ref = referenceQueue.remove();".
Both lines of code are in a block synchronized on the same object (connectionPool). So how can happen what you observe? Two different threads both in a synchronized block on the same object?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
