Type: Feature Request
Status: Resolved (View Workflow)
Affects Version/s: None
Fix Version/s: 3.3
Similar Issues:Show 10 results
JGRP-1595 STABLE: send stable messages to coordinator only JGRP-503 Retransmitted message too large JGRP-266 Faliure of clustering with TCP JGRP-217 unplugging of network cable makes jgroups behave weirdly JGRP-957 Intermittent cluster stability issues JGRP-1195 java.lang.NullPointerException on LazyRemovalCache when doing network glitch testing JGRP-39 A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations JGRP-1533 Two JGoup Server can't communicate each other with multicast JGRP-653 Streaming API for large messages JGRP-1389 Synchronous messages
The time computed for the sending of STABLE is desired_avg_gossip * cluster-size *2. While this is OK for small clusters, it may be too big for large clusters.
On the other hand, if every member simply multicasts a STABLE message every (say) 30 seconds on average, then the number of messages sent grows with increasing cluster size.
Investigate a way to set a lower and upper limit for the making and delivery of STABILITY messages, e.g. the goal is to receive 1 stability message every 60s.
Besides increased traffic, however, this requires everyone to have a TCP connection to everybody else in the cluster in case of a TCP transport.
A better solution might be to have only a dedicated member (the coord) periodically multicast a STABLE message. Everyone replies with a (unicast) STABLE message and when the coord has received STABLE replies from everyone, it multicasts a STABILITY message. This would only require a multicast from the coord to everyone, establishing TCP connections from the coord to everyone (usually already exists because of the VIEW-CHANGE multicast), but everyone would reuse the same TCP connection to send the reply.