Re: [jgroups-dev] Need information about Jgroup communication in jgroups 2.6.5
Bela Ban <[email protected]> Tue, 15 Feb 2011 15:52:36 +0100
| Newsgroups | gmane.comp.java.javagroups.devel |
|---|---|
| Message-ID | <[email protected]> |
2.8 and higher On 2/15/11 1:59 PM, Ashish Giri wrote: > 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