Re: [jgroups-dev] Message explosion in FD_ALL
Bela Ban <[email protected]>
| Newsgroups | gmane.comp.java.javagroups.devel,gmane.comp.java.javagroups.general |
|---|---|
| Message-ID | <[email protected]> |
Mike Jensen wrote:
> Maybe this is a stupid question....(darn, and I missed stupid question
> day: http://en.wikipedia.org/wiki/Ask_a_Stupid_Question_Day)
>
> But why do you even send an "ARE_YOU_ALIVE" to the node? If your not
> receiving heartbeats from the node, what situation would occur where you
> would receive a response "I_AM_NOT_DEAD"?
The double check is optional, and is done in VERIFY_SUSPECT, so if you
don't want it, remove VERIFY_CONFIG from your stack.
The reason for its existence is to reduce false suspicions. Say we have
{A,B,C,D,E}. D suspects E. The double check is done by A. So, in the
case of different network paths, A can possibly have better connectivity
to E than D, so A would drop the suspect and not exclude E from the cluster.
Also, if E is temporarily overloaded, D might generate a spurious
SUSPECT(E). When A double-checks later, the temp spike might be gone.
> I just don't see a case where a reliable heartbeat would get lost,
What do you mean ? The heartbeat is not reliable, it is always under the
UNICAST and NAKACK protocols, so they can indeed get lost.
> but this query response would keep
> the node alive. Have you seen such a situation in the past?
Yes
> If so, do you think this is something I need to attempt in my tree
> mesh FD protocol?
Reducing false suspicions is always a good idea, however, it might
become too costly for a system like treemesh, which is designed for
large scale. I guess nodes leaving and joining is frequent in your
system, so a false suspicion making a node leave and later rejoin is
probably ok.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Javagroups-development mailing list