cluster: release reloading with delay.

[vmihailenco]

/cc @dim

See comment for details.

[vmihailenco]

@dim ping

[dim]

Sorry, busy recently :) I'm no a big fan of artificial delays but the only alternative solution I can think of is a background channel-select loop, where a c.reloading <- struct{}{} channel is triggering a reload.

[vmihailenco]

How that would help? The problem here is that sequence

• start processing command
• get hash slot
• slot moved - reloading
• finish processing

is not synchronized and we can't tell if we need to reload slots or there was a race between reloading and command processing.

[dim]

Sorry, I thought the problem was that:

1. start processing command add license please #1
2. get hash slot, MOVED
3. trigger reloading
4. start processing command Fixed the "Getting started" example for client.set() #2
5. get hash slot, MOVED
6. trigger reloading again

I don't quite understand what you mean by:

there was a race between reloading and command processing

[vmihailenco]

The sequence is:

• cmd1: start processing command
• cmd1: get hash slot
• cmd1: MOVED
• cmd1: trigger reloading
• cmd2: start processing command Fixed the "Getting started" example for client.set() #2
• cmd2: get hash slot
• cmd1: reloading finished
• cmd2: MOVED
• cmd2: trigger reloading

So there is a race between cmd1: reloading finished and cmd2: trigger reloading.

[vmihailenco]

@dim ping

[dim]

I think adding a 1s delay will cause more problems than it solves. You could have a genuine slot reallocation by redis in the meantime. I don't see the 'race' being much on an issue, it will trigger another slot sync, but is this really causing much overhead? I don't believe we will ever end up in a spinning state. If you are really keen to avoid it, why don't compare you compare addr returned by isMovedError against the stored address for that slot? Then, you would only trigger lazyReloadSlots if they are different.

As said, I really don't like artificial delays, they always tend to cause not trivial issues downstream.

[vmihailenco]

@dim done. PTAL

[vmihailenco]

@dim gentle ping. I think I addressed your comment.

[dim]

@vmihailenco really sorry, been pretty busy, LGTM now