ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitchell Rathbun (BLOOMBERG/ 731 LEX)" <mrathb...@bloomberg.net>
Subject Re: Issue with BaselineTopology Branching History
Date Thu, 06 Feb 2020 23:14:33 GMT
A couple more questions after reading the explanation:

-You mentioned each node in the BLT has a consistent id. How is this calculated?

-The branching point hash is a sum of hashcodes of consistent ids of nodes currently in the
BaselineTopology. It is also mentioned that there is a BLT id. How does this relate to the
branching point hash?

-How does the cluster distinguish between a new node joining vs. a node that crashed and rejoined?

From: user@ignite.apache.org At: 02/06/20 07:12:26To:  user@ignite.apache.org
Subject: Re: Issue with BaselineTopology Branching History

Hi Mitchell,

I'm not really sure whether versioning/branching history is covered anywhere
and it looks like it is worth covering.

Branching point hash = sum of hashcodes of BLT nodes consistent id's (long).

Each time baseline topology changes, the previous value is added to the
branching history, id is increased.

The joining node is rejected when couple of things happen (most of them are
baseline changes while being not a part of the cluster):

1. Joining node has greater BLT id than cluster.

2. Cluster BLT id is equals to joining node BLT id, but is not compatible.
That means that cluster branching history does not contains joining node
current BLT hash.

3. Joining node has lesser BLT id than cluster and branching history for
current id does not contain BLT hash of joining node.

PARTITIONED cache with node filter is an alternative to LOCAL cache.

Best regards,
Anton


--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/


Mime
View raw message