Re: [jgroups-users] BUG / Nodes not determining the same merge leader when merging 2 clusters

On 01/09/17 15:54, Questions/problems related to using JGroups wrote:
> Hello,
> 
> First, thanks to JGroups community for all the great work done !

Thanks!

> I’ve been working on a distributed system using JGroups 2.12.1.Final to 
> solve some issues.

No! I'm afraid, but I just lost interest:-)
2.12.1 is ~7 years old; and I don't support such an old version. See [1].

If you insist on staying on 2.12.x, I suggest apply your patch locally 
and create and use a new version.

[1] 
https://github.com/belaban/workshop/blob/master/slides/admin.adoc#problem-4-jgroups-versions


> And I suspect a _bug on “Discovery” class/protocol_.
> 
> ·Environment context
> 
> -JGroups version : 2.12.1.Final
> 
> -11 nodes
> 
> -Tested environment : Ability to split and isolate the network into 2 
> sub networks
> 
> oSub network A of 3 nodes
> 
> oSub network B of 8 nodes
> 
> -JGroups configuration using TCPPING -> see attached file
> 
> ·Issue : Nodes not determining the same merge leader when merging 2 clusters
> 
> ·Problem analysis :
> 
> MERGE2 triggers a scheduled task with a fixed delay to discover new 
> groups in regular basis. It sends an event ‘FIND_ALL_VIEWS’ down from 
> the protocol stack. It is handled by TCPPING which is responsible to 
> build and send a PING to all initial hosts set in jgroups configuration 
> files. PING is a ‘GET_MBRS_REQ’ message to discover new groups. As it is 
> implemented in JGroups 2.12.1  and as it is shown below in 
> “Discovery.java” class, the ‘GET_MBRS_REQ’ message is handled by the 
> distant “initial hosts” only if the message is coming from a member in 
> different view. Otherwise, the message is discarded.
> 
>      public Object up(Event evt) {
> 
>          switch(evt.getType()) {
> 
>              case Event.MSG:
> 
>                  …
> 
>                  switch(hdr.type) {
> 
>                      case PingHeader.GET_MBRS_REQ:   // return 
> Rsp(local_addr, coord)
> 
>                          …
> 
>                          if(return_entire_cache && hdr.view_id == null 
> && rank != 0) {
> 
>                              …
> 
>                          }
> 
>                          else {
> 
>                              if(hdr.view_id != null) {
> 
>                                  // If the discovery request is 
> merge-triggered, and we the ViewId shipped with it
> 
>                                  // is the same as ours, we don't 
> respond (JGRP-1315).
> 
>                                  ViewId my_view_id=view != null? 
> view.getViewId() : null;
> 
>                                  if(my_view_id != null && 
> Util.sameViewId(my_view_id, hdr.view_id))
> 
>                                      return null;
> 
>                              }
> 
>                          …
> 
> When the new subgroups discovered is returned back to the MERGE2 
> protocol stack, and if the current node is coordinator, it adds its 
> group to the discovered ones to determine the “merge leader”.
> 
> *private*List<PingData> findAllViews() {
> 
>              List<PingData> 
> retval=(List<PingData>)down_prot.down(*new*Event(Event./FIND_ALL_VIEWS/));
> 
> *if*(retval == *null*) *return*Collections./emptyList/();
> 
> *if*(is_coord&& local_addr!= *null*) {
> 
>                  PingData tmp=*new*PingData(local_addr, view, *true*);
> 
> //let's make sure that we add ourself as a coordinator
> 
> *if*(!retval.contains(tmp))
> 
>                      retval.add(tmp);
> 
>              }
> 
> *return*retval;
> 
>          }
> 
> *** The issue *** is that it happens that a non-coordinator node 
> triggered the FindSubgroupsTaskin MERGE2 protocol stack when merging 
> clusters. The result is that it ends off a different groups discovered 
> and different merge leader determined, which may cause merge to fail !
> 
> ·Solution : Fix the regression introduced by JGRP-1315 by responding to 
> the GET_MBRS_REQ when the ‘GET_MBRS_REQ’ message receiver is coordinator.
> 
> ·Below is the proposed patch in Discovery.java :
> 
> *if*(hdr.view_id!= *null*) {
> 
> // If the discovery request is merge-triggered, and we the ViewId 
> shipped with it
> 
> // is the same as ours, we don't respond (JGRP-1315).
> 
>                                  ViewId my_view_id=view!= *null*? 
> view.getViewId() : *null*;
> 
> - *if*(my_view_id != *null*&& Util./sameViewId/(my_view_id, hdr.view_id)) {
> 
> + *if*(my_view_id != *null*&& Util./sameViewId/(my_view_id, hdr.view_id) 
> && !Util./isCoordinator/(view, local_addr)) {
> 
> log.debug("... Not responding to 'GET_MBRS_REQ' [ping_view_id="+ 
> hdr.view_id+ ", my_view_id="+ my_view_id + ", rank="+ rank+ "]");
> 
> *return**null*;
> 
>                                  }
> 
>                              }
> 
> Many thanks,
> 
> Thomas UNG
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
> 

-- 
Bela Ban | http://www.jgroups.org


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot