redis / redis

Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.

Home Page:http://redis.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] Redis key present in cache even after deleted by first thread and reading around same point of time by other thread.

ParasGH opened this issue · comments

When one thread deleted the cached key and around same point of time another thread doing following task Redis responded incorrectly:
Retrieving remaining time to live response is null.
Checking whether key exist or not: key present in cache even after deleted by first thread.
Checking value of key: value present in cache even after deleted by first thread.

To reproduce

Delete the key by a thread.
With other thread at same time check key exist or not after deleted by first thread.
Result: Key exists

Expected behavior
Key should not exist after deleted.

"around same point of time" is vague, and doesn't give enough information to know whether the server is doing anything incorrect here. Delays and overtakes are possible at pretty much every point unless you are talking about two messages on the same connection being processed out of order, so for close events: it becomes very hard to say which cam first - the GET or the DEL/UNLINK, i.e. what evidence do you have for the "after" in the sentence "after deleted by first thread"?

"around the same point" means first thread deleted the key then after few mill/microseconds second thread check key existence. The evidence for "after" based on retrieving remaining time to live for key as NULL after deleted by first thread even key having enough remaining time to live before deleting the key.

Looking forward for fixes of issue, is any progress?

@ParasGH did you confirm that the messages of the two threads are delivered in the order you expect?
could you try to use MONITOR to verify it?