Noted Brian. We over engineered FLUSH in 2.5 release and in 2.6 release
which is due next week these kind of issues should not happen.
I'll try AS-HEAD with JGroups HEAD before ship it as 2.6.
Brian Stansberry wrote:
Is your server bound to your VPN interface?
> GMS: address is 10.11.14.31:32796
This sounds very similar to what the dev90 machine was experiencing
when doing hudson testsuite runs. There, multicast wasn't working
properly on the bound interface. FLUSH counts on getting back a
response to its own multicast, which it would never get. So, every
startFlush would hang for timeout * retries.
This gives me a chance to bring up something with the JGroups guys:
The behavior we see when FLUSH fails seems not so great -- long delay
and then a WARN. At least in some cases, like initial channel
connection, it would be better if it the connect() just failed. The
channel is not usable.