You need to be a bit more specific, what exactly happened and what
symptoms did it cause?
The leader sends a periodic heartbeat to prevent followers from trying
to become leaders.
These heartbeat messages are sent _unreliably_, ie. they may get dropped
and there is no retransmission performed by JGroups.
In case a follower doesn't receive a couple of heartbeats, it may select
to become leader by starting an election. However, to actually become
leader, it requires a majority of votes, and that's unlikely unless a
majority of members didn't receive their heartbeats, either.
In the unlikely case the new would-be leader does indeed get a majority
of votes (and has the longest log), it would become the new leader, but
this is fine, and entirely within the scope of the Raft protocol.
On 14/04/17 14:10, 赵琦 wrote:
> Hi Bela,
>
> I means the Heartbeat of raft protocol. I observed that the heartbeat of
> raft protocol some times was not send to follower in time an case election.
>
> Thanks,
> Qi
>
> 在 2017年4月13日星期四 UTC+8下午3:21:08,Bela Ban写道:
>
> Are you referring to FD_ALL? A heartbeat sent by this protocol should
> never block anything...
>
> On 13/04/17 03:26, 赵琦 wrote:
> > Hi Bela,
> >
> > Is is possible that user data sending will block heartbeat
> package. When
> > I test jgroups-raft on 4 node cluster, I find that some times
> heartbeat
> > will delay and cause election timeout.
> >
> > Thanks,
> > Qi
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "jgroups-raft" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to
jgroups-raft...@googlegroups.com <javascript:>
> > <mailto:
jgroups-raft...@googlegroups.com <javascript:>>.
> <javascript:>
> > <mailto:
jgroup...@googlegroups.com <javascript:>>.
> <
https://groups.google.com/d/msgid/jgroups-raft/dbe18210-582e-4995-ad10-22414e023ee3%40googlegroups.com?utm_medium=email&utm_source=footer
> <
https://groups.google.com/d/optout>.