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

Yes. I'm always grateful for pull requests fixing issues, but for a 
current version. This would be either master or the 3.6 branch, anything 
else I'm not interested.

I do know of folks though who maintain their own branches with fixes, 
until they can move to a 'supported' and recent release. Fair enough if 
it works for them.
Cheers,

On 01/09/17 16:55, Questions/problems related to using JGroups wrote:
> Thanks a lot for the quick answer !
> 
> I guess that would be THE answer. But I had no choice but working on this version. The goal was to fulfill the obligation to report any code change on open source software !
> 
> I did 2 others bug fixes on FD protocol stacks ... And I assume that the answer would be the same !
> 
> Thanks a lot again ! ;-)
> Thomas
> 
> -----Message d'origine-----
> De : Questions/problems related to using JGroups [mailto:[email protected]]
> Envoyé : vendredi 1 septembre 2017 16:41
> À : [email protected]
> Objet : 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
_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users