Following the pipelining approach here, we often pipeline requests (Setting and then getting) in our application. We noticed after upgrading to StackExchange.Redis 2.1.30 that the order of requests would very infrequently not be respected and that the get operation would return the old redis value, despite having pipelined the set operation first.
We update a hash and the retrieve the hash following pipelining guidelines. Here is a sample application that does this repeatedly in a loop.
The relevant part of the code:
long i = 0;
while (true)
{
int val = random.Next();
var a = db.HashSetAsync("foo", new[] { new HashEntry("a", val) });
var b = db.HashGetAllAsync("foo");
await Task.WhenAll(a, b);
var foo = await b;
var test = foo.ToDictionary(i => i.Name, i => i.Value);
if (test["a"] != val) // problem occurs here
throw new Exception($"Wrong value {val}")
if (++i % 100_000 == 0)
Console.WriteLine($"{i:N0} successful iterations");
}
The application will after a while return the incorrect value which indicates that the HashSetAsync did not occur before we retrieved the value using HashGetAllAsync
Unhandled exception. System.Exception: Wrong value 1315285639
at RedisTest.Program.Main(String[] args) in C:\work\RedisTest\RedisTest\Program.cs:line 26
at RedisTest.Program.<Main>(String[] args
I've tested this with StringSetAsync and StringGetAsync and the same issue occurs after a number of runs.
This is pretty critical issue in a production environment as this causes our applications to be in incorrect state. To circumvent this, we've started using batching to batch the two requests together which seems to so far alleviate the problem.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4