> On Oct. 20, 2015, 6:13 p.m., Jianxia Chen wrote:
> > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java,
> >  line 288
> > <https://reviews.apache.org/r/39488/diff/1/?file=1102050#file1102050line288>
> >
> >     Should it return false here? If it returns true here, which means 
> > doCheckMember call is successful for the dead member. I am confused.

Thanks Jianxia.

The point of the test hook in this method is to keep it from attempting to 
contact other members.  The playingDead member is supposed to go silent, so I 
don't want it sending suspect messages to other processes.  The suspect 
messages themselves would be treated as heartbeats by the health monitor.  So, 
no it should not return false.

I'll add a comment to that effect.


- Bruce


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39488/#review103287
-----------------------------------------------------------


On Oct. 20, 2015, 6:01 p.m., Bruce Schuchardt wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39488/
> -----------------------------------------------------------
> 
> (Updated Oct. 20, 2015, 6:01 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, Jianxia Chen, and 
> Lynn Gallinat.
> 
> 
> Repository: geode
> 
> 
> Description
> -------
> 
> The JoinLeave service was using both a viewInstallationLock and a stateLock.  
> If we were installing a view and found we needed to become the membership 
> coordinator we would have a sync on the first and then get a write-lock on 
> the second.  If we were becoming coordinator and installing a new view we 
> sould have the write-lock and then try to get a sync on the 
> viewInstallationLock.  This caused deadlock.
> 
> The solution is to remove the stateLock and just use the 
> viewInstallationLock.  We were only using the write-lock on the stateLock 
> anyway.
> 
> This change-set also has some improvements to the beSick/playDead test-hook 
> methods.
> 
> 
> Diffs
> -----
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java
>  9d870147c4e073da9482302ca4ef68be56da051c 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  4ebc20cb0ddf1ff86607432ecb67eeefff4ed685 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  7f6a40ee1430a0a89be805f4445db63527527c65 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  50dc99e8c43212f94fe3120bdcbff2252d7951c5 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>  d29a6ddc44520fd1525f51c85be1fcb22b47caac 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/management/ClientHealthStatsDUnitTest.java
>  891cb601bc8dde12dffeb0c225debd3644740307 
> 
> Diff: https://reviews.apache.org/r/39488/diff/
> 
> 
> Testing
> -------
> 
> all unit tests, external integration testing
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Reply via email to