Re: [jgroups-users] Migration Question/Issue

On 09/10/18 18:17, Questions/problems related to using JGroups via 
javagroups-users wrote:
> First off, appreciate the feedback!
> 
> We will try MERGE3 in our testing to see if that resolves our issue.  Where exactly in our stack should MERGE3 reside?

Directly over the discovery protocol and below the failure detection 
protocols. Take a look (e.g.) at udp.xml, shipped with JGroups

> The purpose of our migration is based upon the vulnerability reported with 3.x version.

OK. You may want to test with 4.0.12, which does not yet have the code 
for coord-leaving...

> We previously used ENCRYPT and must still use ASYM_ENCRYPT so removing it is not one of our options.
> I did see that bug reported, any ideas on when that bug may be addressed?

It is high on my prio list, but I'm away for the better part of the next 
two weeks, so I hope tobe able to tackle it then.

Note that with ASYM_ENCRYPT and change_key_on_leave set to true, MERGE3 
may always be needed to cover edge cases, quasi as a second line of defense

> I tested the lock service in our application after migration and still seemed to work as expected.

OK, good to know

> CJ Binder
> 
> -----Original Message-----
> From: Questions/problems related to using JGroups <[email protected]>
> Sent: Tuesday, October 9, 2018 7:41 AM
> To: [email protected]
> Subject: Re: [jgroups-users] Migration Question/Issue
> 
> I see that you don't have MERGE3 on the stack: note that [1] is a fix (not yet resolved) which will make coord leaving behave correctly.
> 
> Does this work correctly if you remove ASYM_ENCRYPT?
> 
> Also note that having both a LockService *and* a MessageDispatcher on top of the same channel will likely not work (hasn't been tested): if you want this, use ForkChannels.
> 
> It would be easier if you came up with a *compilable* small test program (and instructions) that showed the issue...
> 
> [1] https://issues.jboss.org/browse/JGRP-2293
> 
> On 05/10/18 22:33, Questions/problems related to using JGroups via javagroups-users wrote:
>> Good Day,
>>
>> We are currently attempting to migrate from 3.3.3 to 4.0.15.  I
>> couldn't find any migration guides so the following is our previous
>> setup and current setup.  What we are experiencing is that when a
>> participant leaves the cluster when it's a hard crash(kill jvm), some
>> of the participants are not notified(Coordinator is) and still think
>> other members exist and attempt to send messages to them locking up
>> the application until the timeout of 2 minutes occurs.  When this
>> happens on the Coordinator, the oldest participant is notified and
>> takes over Coordinator role, however the other participants do not get notified.
>> In our setup, we use the Message Dispatcher to send sync or asyn
>> messages to and from 1 or 1 to many members.  Within our
>> ClusterMembershipListener, we only have application code within the
>> viewAccepted method of the interface.   Any help would be greatly
>> appreciated.
>>
>> _Testing Scenario_
>>
>>    * Scenarios 1
>>        o Start APP A (Coordinator)
>>        o Start APP B (Participant)
>>        o Start APP C (Participant)
>>        o Kill APP C(Hard kill of process)
>>        o Verify A can talk to B
>>        o Verify B can talk to A
>>    * Scenarios 2
>>        o Start APP A (Coordinator)
>>        o Start APP B (Participant)
>>        o Start APP C (Participant)
>>        o Kill APP A(Hard kill of process)
>>        o Verify B takes over as Coordinator
>>        o Verify B can talk to C
>>        o Verify C can talk to B
>>
>> _Issues_
>>
>>    * Scenario 1
>>        o Works
>>            + Applications on the same machine
>>        o Fails
>>            + Applications are on other machines in same network
>>                # APP C still thinks that APP A is coordinator,
>>                  viewAccepted not invoked
>>        o Possible Fix
>>            + Tried setting on GMS - use_delta_views = FALSE
>>            + This seemed to fix the issue but then ran Scenario 2 still
>>              an issue
>>    * Scenario 2
>>        o Works
>>            + Applications on the same machine
>>        o Fails
>>            + Applications are on other machines in same network
>>                # APP B does take over as Coordinator but then is
>>                  constantly sending Suspect messages to APP A
>>                # APP C still thinks App A is Coordinator and continues to
>>                  send messages to it
>>
>> _Migration Changes Made_
>>
>>    * ENCRYPT changed to ASYM_ENCRYPT
>>        o The previous location of encrypt was not working due to key
>>          exchange.  It was moved up before nakack2 and seems to work in
>>          our testing now.
>>    * UNICAST2 changed to UNICAST3
>>    * Address is no longer serializable, so we now store the mostSig and
>>      leastSig values in the objects.  We have many messages that include
>>      objects that store the Address of where the object comes from.  This
>>      is so we know who to send specific message to.  After this change
>>      messages are sent and received successfully
>>    * Removed UFC Protocol as logging stated it is not necessary and is
>>      safe to remove.
>>    * Changed how the protocol is supplied to channel as old way is no
>>      longer supported.
>>
>> _3.3.3 (Custom Protocol Stack Initialization)_
>>
>> channel= *new*JChannel(*false*);
>>
>> channel.setName(SystemInfo./getName/());
>>
>> channel.enableStats(ClusterConstants.*/STATS_ENABLED/*);
>>
>>                 ProtocolStack stack= *new*ProtocolStack();
>>
>> stack.enableStats(ClusterConstants.*/STATS_ENABLED/*);
>>
>> channel.setProtocolStack(stack);
>>
>> stack.addProtocol(getTCPProtocol());
>>
>> *if*(initialMembers!= *null*) {
>>
>> stack.addProtocol(getTCPPingProtocol());
>>
>>                 }
>>
>> stack.addProtocol(getFDSockProtocol());
>>
>> stack.addProtocol(getFDAllProtocol());
>>
>> stack.addProtocol(getVerifySuspectProtocol());
>>
>> stack.addProtocol(getNakack2Protocol());
>>
>> stack.addProtocol(getUnicast2Protocol());
>>
>> stack.addProtocol(getCentralLockProtocol());
>>
>> stack.addProtocol(getStableProtocol());
>>
>> stack.addProtocol(getAuthProtocol());
>>
>> stack.addProtocol(getGMSProtocol());
>>
>> stack.addProtocol(getUfcProtocol());
>>
>> stack.addProtocol(getMfcProtocol());
>>
>> stack.addProtocol(getEncryptProtocol());
>>
>> stack.addProtocol(getFrag2Protocol());
>>
>> stack.init();
>>
>> channel.setDiscardOwnMessages(*true*);
>>
>> dispatcher= *new*MessageDispatcher(channel, *null*,
>>
>> *new*ClusterMembershipListener(), *new*ClusterMessageReceiver());
>>
>> lockService= *new*LockService(channel);
>>
>> channel.connect(ClusterConstants.*/CLUSTER_NAME/*);
>>
>> _4.0.15 (Custom Protocol Stack Initialization)_
>>
>> List<Protocol> protocols= *new*ArrayList<Protocol>(14);
>>
>> protocols.add(getTCPProtocol());
>>
>> *if*(initialMembers!= *null*) {
>>
>> protocols.add(getTCPPingProtocol());
>>
>>                 }
>>
>> protocols.add(getFDSockProtocol());
>>
>> protocols.add(getFDAllProtocol());
>>
>> protocols.add(getVerifySuspectProtocol());
>>
>> protocols.add(getAsymEncryptProtocol());
>>
>> protocols.add(getNakack2Protocol());
>>
>> protocols.add(getUnicast3Protocol());
>>
>> protocols.add(getCentralLockProtocol());
>>
>> protocols.add(getStableProtocol());
>>
>> protocols.add(getAuthProtocol());
>>
>> protocols.add(getGMSProtocol());
>>
>> protocols.add(getMfcProtocol());
>>
>> protocols.add(getFrag2Protocol());
>>
>> channel= *new*JChannel(protocols);
>>
>> channel.setName(SystemInfo./getName/());
>>
>> channel.setStats(ClusterConstants.*/STATS_ENABLED/*);
>>
>> channel.getProtocolStack().enableStats(ClusterConstants.*/STATS_ENABLE
>> D/*);
>>
>> channel.setDiscardOwnMessages(*true*);
>>
>> dispatcher= *new*MessageDispatcher(channel,
>>
>> *new*ClusterMessageReceiver());
>>
>> dispatcher.setMembershipListener(*new*ClusterMembershipListener());
>>
>> lockService= *new*LockService(channel);
>>
>> channel.connect(ClusterConstants.*/CLUSTER_NAME/*);
>>
>> CJ Binder
>>
>>
>>
>>
>>
>> _______________________________________________
>> javagroups-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>
> 
> --
> Bela Ban | http://www.jgroups.org
> 
> 
> 
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
> 
> 
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
> 

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



_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users