investigate edge cases, where queried neighbour node (when joining or leaving) is own VS #80

New issue

Open

opened 2020-10-08 10:21:03 +02:00 by schmittlauch · 2 comments

schmittlauch commented

2020-10-08 10:21:03 +02:00

Owner

When joining or leaving a vs to/from a DHT, the neighbour of the vs in question is queried for their load to calculate the load matches.
What happens if the node joining on/ the node shedding the own load onto when leaving is a vserver of the same RealNode?

Do some example calculations for

join and successor is own VS
depart and successor is own VS

When joining or leaving a vs to/from a DHT, the neighbour of the vs in question is queried for their load to calculate the load matches. What happens if the node joining on/ the node shedding the own load onto when leaving is a vserver of the same RealNode? Do some example calculations for - join and successor is own VS - depart and successor is own VS

schmittlauch added this to the k-choices load balancing milestone 2020-10-08 10:21:03 +02:00

schmittlauch added the

DHT

test case

labels 2020-10-08 10:21:04 +02:00

schmittlauch commented

2020-10-08 22:47:04 +02:00

Author

Owner

Special cases of the edge cases above: The own vs queried is the one that's departing/ relocating.

schmittlauch commented

2020-10-09 02:13:41 +02:00

Author

Owner

Let X be a neighbour node, O an active vserver to be relocated and | the position to be relocated to.
Then the following state of the DHT can trigger an edge case:

--O---|---X--

With O still being joined on the DHT and investigating the future load of the still unjoined |, X returns the load of the slice from O to X (forwards).
But the load actually put onto | after relocating to that position is the slice from X to | (forwards), so the previous query result was missing the slice from X to O.

circumstances triggering this edge case:

new position is a direct predecessor of old position

Let `X` be a neighbour node, `O` an active vserver to be relocated and `|` the position to be relocated to. Then the following state of the DHT can trigger an edge case: `--O---|---X--` With `O` still being joined on the DHT and investigating the future load of the still unjoined `|`, `X` returns the load of the slice from `O` to `X` (forwards). But the load actually put onto `|` after **relocating** to that position is the slice from `X` to `|` (forwards), so the previous query result was missing the slice from `X` to `O`. circumstances triggering this edge case: - new position is a direct predecessor of old position