hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Deadlock problem with MultiThreadedHttpConnectionManager
Date Wed, 18 Jun 2003 15:29:45 GMT
> It's not clear to me how this can be a dead lock.

I'm not sure of the exact definition of deadlock but I think it requires 
two threads to be waiting for each other.  This is not what's happening 
in this case.  The problem is that the thread is waiting and noone is 
going to wake it up.

> 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?

We allow a 0 timeout indicating an infinite wait.  This is in fact the 
default.

>> 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?

This second thread is not waiting on the same lock.  It is a thread 
waiting for garbage collected connections.

Mike


Mime
View raw message