[Compatibility] Added CLIENT UNBLOCK command

[Vijay-Nirmal]

Adding the CLIENT UNBLOCK command to garnet

• Add CLIENT UNBLOCK commands
• Add Integration Test cases and ACL Test
• Add documentation

[TalZaccai]

Thanks! Please see my comments.

[TalZaccai]

The client may be unblocked between you checking if it's blocked and attempting to unblock it (in which case you should return 0). In other words, you should get some feedback from the observer that indicates if you initiated the unblocking or not.

[Vijay-Nirmal]

I have moved this inside the if, I think that should work as expected, because only why this like can execute observer.CancellationTokenSource.Cancel() or observer.ResultFoundSemaphore.Release() is called. Let me know, If I understood it wrongly.

[TalZaccai]

You can still have a context switch happen here. What you need to do is have something similar to observer.HandleSetResult (say, observer.TryForceUnblock) that locks the ObserverStatusLock, and returns a boolean that indicates if the observer was force unblocked or not.

[TalZaccai]

This will also be true if the session was disposed

[Vijay-Nirmal]

That should cause any issue right? earlier its just an empty catch, Now I am assigning a bool. Do you see any issue with that?

[TalZaccai]

Yes, because if the session was disposed you wouldn't need to return a CollectionItemResult.Error

[TalZaccai]

Can add a couple more tests here, for example -
1 client blocks, send 1 force unblock and 1 add in parallel - check that either client gets the data or gets unblocked and data stays in collection, can repeat test multiple times.
Multiple clients blocking, multiple calls for force unblock & add in parallel - check that no added data gets lost (i.e. either stays in the collection or being returned to clients).

[Vijay-Nirmal]

Added a test concurrency, everything is working as expected. One finding is that, there could be multiple clients get the response as 1 if they are unblocking the same client. I would say it's expected as there is no point in having transactions for unblocking client ID.

Another interesting things I found is there is an issue with the list push command where if we push multiple items in then somehow all items values are just the same as last item's value. I will find the root cause and fix it as part of a separate PR

for (int i = 0; i < 20; i++)
{
    addTasks.Add(Task.Run(() => redis.GetDatabase(0).ListLeftPush(key, $"{value}{i}")));
}
await Task.Delay(1000)
var resultInScreenshot = db.ListRange(key).Select(x => (string)x).ToArray();

Edit: Even though I am not able to create any issues with concurrent add command, blocking command and unblock command. I am pretty sure if I try hard I can create an issue here because the observer is not part of the transaction. But I don't think this should be an issue for Garnet as it doesn't corrupt any original data.

[TalZaccai]

• I think that only 1 client should get a result of 1, this happens do to the thread-unsafety in ClientCommands (see my comment there).
• That's a good find - please let me know if you need any help here, this should be fixed promptly as it corrupts the data.

[badrishc]

Another interesting things I found is there is an issue with the list push command where if we push multiple items in then somehow all items values are just the same as last item's value. I will find the root cause and fix it as part of a separate PR

for (int i = 0; i < 20; i++)
{
    addTasks.Add(Task.Run(() => redis.GetDatabase(0).ListLeftPush(key, $"{value}{i}")));
}
await Task.Delay(1000)
var resultInScreenshot = db.ListRange(key).Select(x => (string)x).ToArray();

This is a bug in your client code, not the server. You need to capture the i values correctly - something like this:

            for (int i = 0; i < 20; i++)
            {
                var _i = i;
                addTasks.Add(Task.Run(() => redis.GetDatabase(0).ListLeftPush(key, $"{value}{_i}")));
            }

[Vijay-Nirmal]

@badrishc Ohh yaa, a rookie mistake from my end

[Vijay-Nirmal]

Fixed the review commands

[TalZaccai]

Thanks! Please see remaining comments :)

[TalZaccai]

Same comment here about running CommentInfoUpdater - #864 (comment)