[infinispan-dev] Put issues with newly joining node

[Bela Ban]

On 12/5/12 12:06 PM, Galder Zamarreño wrote:
> On Dec 4, 2012, at 11:52 AM, Bela Ban <bban at redhat.com> wrote:
>
>> If a node A connects to B and B connects to A at the exact same time
>> (and there wasn't any existing connection between the 2 nodes, then one
>> of the 2 will 'win' and the other one will close its connection. The
>> message to be sent is then lost.
>>
>> This is corrected by one of the upper layers, e.g. UNICAST retransmits
>> the message until it gets an ack. Re-sending a message will then create
>> a new connection, if the existing one was closed / removed.
>>
>> However, with UNICAST2, if a given message was the last message and no
>> further messages are sent, then only UNICAST2's stability messages will
>> detect that the other node is missing the last message sent. Stability
>> is triggered every 60 seconds by default, so unless that property was
>> changed, or stability was triggered programmatically, that last (lost)
>> message won't get retransmitted for 60 seconds.
> ^ Isn't that a default too high?

Assuming that the size-based stable messages are the norm, then 
time-based only kicks in as a second line of defense. With 
https://issues.jboss.org/browse/JGRP-1548 in place, this becomes even 
less important, so I want to leave it high as it does generate some 
traffic when set too small.


> Seems to me the scenario explained could happen relatively easily if two nodes are started simultaneously.

No, the startup won't trigger concurrent connections, as only the joiner 
connects to the coordinator and the coordinator reuses the same 
connection to send the JOIN-RSP back.

It is the rebalancing process that triggers this in certain cases; the 
forwarding of state transfer requests to different owners.

> We no longer ask users to stagger their startups?

Because concurrent startup works, and not having to stagger startup is 
simpler.

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)