Re: [jgroups-dev] Need information about Jgroup communication in jgroups 2.6.5

Ashish Giri <[email protected]> Tue, 15 Feb 2011 18:29:14 +0530
Newsgroups gmane.comp.java.javagroups.devel
Message-ID <D978F4460A9DFC49AD99720E49821F9C46F9F501@EXCHANGE.persistent.co.in>
Hi Bela,

I was going through your blog http://belaban.blogspot.com/2009/04/those-damn-edge-cases.html.

It seems that we are also facing similar kind of issue. We are using 2.6.5 version.

Could you please confirm which version of jgroups include fix for above UNICAST related bug?

Thanks,
Ashish Giri

-----Original Message-----
From: Bela Ban [mailto:[email protected]] 
Sent: Monday, February 14, 2011 12:28 PM
To: [email protected]
Subject: Re: [jgroups-dev] Need information about Jgroup communication in jgroups 2.6.5



On 2/13/11 3:07 PM, Ashish Giri wrote:
> Hi Team,
>
>
>
> We are stuck to a scenario when we have three servers[A, B and C].All three
> servers are interconnected.
>
>
>
> What will happen if route to B from A is disconnected. However B is still
> reachable from C and C is reachable from A.
>
>
>
> How view will be represented in this case in each server?

It depends on the failure detection protocols and on who is coordinator. 
Assuming A is coordinator and VERIFY_SUSPECT is in the stack, the 
following will happen:
- In FD, A pings B, B pings C and C pings A
- A won't get any heartbeat acks from B
- A suspects B and broadcasts a SUSPECT event
- A's VERIFY_SUSPECT will try to reach B again, but doesn't get any response
- A excludes B and installs the new view {A,C} in  A and C
- B still has view {A,B,C}
- When B tries to ping C, C shuns B
- B then leave the cluster and tries to reconnect. Because it cannot 
talk to A, this will go on forever


You can actually simulate the above case easily by adding <DISCARD 
use_gui="true"/> just above UDP. This will pop up a dialog box, in which 
you can interactively drop communication  to/from any member, even 
asymmetric links are possible (A can talk to B. but B cannot talk to A).

The above behavior was changed in 2.8: shunning [2] doesn't exist 
anymore, it was replaced by merging, and merging was also improved to 
handle asymmetric cases [1].


[1] http://belaban.blogspot.com/2009/04/those-damn-edge-cases.html
[2] http://belaban.blogspot.com/2009/06/shunning-has-been-shunned.html


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Javagroups-development mailing list


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Javagroups-development mailing list