This content has been marked as final.
Show 3 replies
-
1. Re: Failover possible dead lock
timfox Jan 29, 2007 7:02 PM (in response to clebert.suconic)I don't think this is a deadlock - deadlock implies a race for two exclusive locks:
thread 1 gets lock on resource A.
thread 2 gets lock on resource B
thread 1 tries to get lock on resource B and blocks
thread 2 tries to get lock on resource A and blocks
However, it's still an issue.
Can't you interrupt the receive thread, to cause it to return? -
2. Re: Failover possible dead lock
clebert.suconic Jan 29, 2007 7:20 PM (in response to clebert.suconic)"Tim Fox" wrote:
I don't think this is a deadlock - deadlock implies a race for two exclusive locks:
Well.. I know technical name wouldn't be dead lock...
But you will still be waiting forever on a writeLock, that will never occur. (you're dead anyway :-) )
I guess I could call Failover to notify the receive thread.. yes... but I just don't think it would be a good solution. The way it works now, we only start failure detection after we close the valve. We can't close the valve if there is an invocation pending.
I would prefer using the Valve only on places where a server communication is needed. On that case we don't have a problem as we will aways get an IOException or a CannotConnectException when the server dies.
A receive is only waiting on an internal buffer and I don't see any problems on letting it wait Callback to be re-established and feed the buffer again after failover.
I have talked to Ovidiu by IM, and he thinks it would make sense to use the Valve only on places where an IO to the server is being performed.