On 12/5/12 12:06 PM, Galder Zamarreño wrote: > On Dec 4, 2012, at 11:52 AM, Bela Ban <[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
