It wasn't causing an issue but there's nothing that will ever clear the
joinResponse array after it has finished joining, so if we store it in
this method the response message would just sit taking up space forever.
Le 5/11/2016 à 10:08 AM, Hitesh Khamesra a écrit :
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/47189/
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java
<https://reviews.apache.org/r/47189/diff/2-3/?file=1379770#file1379770line1138>
(Diff revisions 2 - 3)
protected Object sendCoordinatorFindRequest(InetSocketAddress addr,
FindCoordinatorRequest request, int connectTimeout)
1138
if (!this.isJoined) {
Curious, What issue it was causing?
- Hitesh Khamesra
On May 11th, 2016, 5:05 p.m. UTC, Bruce Schuchardt wrote:
Review request for geode, Hitesh Khamesra, Jianxia Chen, and Udo
Kohlmeyer.
By Bruce Schuchardt.
/Updated May 11, 2016, 5:05 p.m./
*Repository: * geode
Description
This reinstates the sending of JoinResponseMessages so that the new
member can get the jgroups multicast digest. The JoinResponseMessages
are sent after installing the new membership view, so JGroupsMessenger
has been changed to use MERGE_VIEW instead of SET_VIEW to install the
digest since it may have already received multicast messages from some
members.
Testing
precheckin is underway. There is already a unit test checking that a
digest is added to a JoinResponseMessage so I didn't need to write one.
Diffs
*
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeave.java
(88e4d496e5d89f2b84d5e755fc6471c8790ed98f)
*
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
(4a54e8433ccf0bcfdacc3ccc6e790381da6e236a)
*
geode-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
(50bed13419d1ed68a405a9f5ed5d5543c3d98813)
View Diff <https://reviews.apache.org/r/47189/diff/>
