> On Feb. 2, 2016, 4:51 p.m., Bruce Schuchardt wrote: > > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java, > > line 2164 > > <https://reviews.apache.org/r/43059/diff/2/?file=1228853#file1228853line2164> > > > > This block of code could be replaced with filterLeavingMembers like you > > did in the new code.
changed to new filterRequests function > On Feb. 2, 2016, 4:51 p.m., Bruce Schuchardt wrote: > > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java, > > line 2258 > > <https://reviews.apache.org/r/43059/diff/1-2/?file=1228606#file1228606line2258> > > > > Members who have sent a Leave request are healthy and should not be > > considered crashed, so they should not be put back into the mbrs > > collection. Only the Removed members that we haven't received a Leave from > > should be put back into mbrs. > > > > So, get rid of the if(!newLeaves.isEmpty) block and change the other to > > this: > > > > if (!newRemovals.isEmpty()) { > > newRemovals.removeAll(newLeaves); > > mbrs.addAll(newRemovals); > > } Thanks. I missed this line "mbrs.removeAll(newLeaves);" > On Feb. 2, 2016, 4:51 p.m., Bruce Schuchardt wrote: > > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java, > > line 2278 > > <https://reviews.apache.org/r/43059/diff/2/?file=1228853#file1228853line2278> > > > > "removalRequestForMembers" isn't a good name for this parameter since > > they might be Remove requests or Leave requests. Call it "requestIDs" or > > something without "remove" in the name. changed to filterMembers - Hitesh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/43059/#review117414 ----------------------------------------------------------- On Feb. 2, 2016, 12:11 a.m., Hitesh Khamesra wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/43059/ > ----------------------------------------------------------- > > (Updated Feb. 2, 2016, 12:11 a.m.) > > > Review request for geode, Bruce Schuchardt and Udo Kohlmeyer. > > > Repository: geode > > > Description > ------- > > ViewCreator thread sends another message when any member doesn't ack back to > prepared view. And then it waits on future as this can happen for > multiple members. > In this case, If those members are not responsive and other thread > already determined that, > then we don't need to wait for those members. Thus now viewCreator thread > checks > RemoveMember message for those members while waiting for response. > Another minor fix in same area. > And added unit test for that > > > Diffs > ----- > > > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/fd/GMSHealthMonitor.java > b6f6c12 > > gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java > 6b09214 > > gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java > 5b53290 > > Diff: https://reviews.apache.org/r/43059/diff/ > > > Testing > ------- > > > Thanks, > > Hitesh Khamesra > >
