summaryrefslogtreecommitdiff
path: root/src/server.c
diff options
context:
space:
mode:
authorguybe7 <guy.benoish@redislabs.com>2022-10-18 18:50:02 +0200
committerGitHub <noreply@github.com>2022-10-18 19:50:02 +0300
commitb57fd01064428ab388c9d9038a617a52488a447b (patch)
tree82bcfcf7355292dcdbd8da8d56b149cedb10da56 /src/server.c
parentb43f254813025e3deea6ef65126ea2bad49af857 (diff)
downloadredis-b57fd01064428ab388c9d9038a617a52488a447b.tar.gz
Blocked module clients should be aware when a key is deleted (#11310)
The use case is a module that wants to implement a blocking command on a key that necessarily exists and wants to unblock the client in case the key is deleted (much like what we implemented for XREADGROUP in #10306) New module API: * RedisModule_BlockClientOnKeysWithFlags Flags: * REDISMODULE_BLOCK_UNBLOCK_NONE * REDISMODULE_BLOCK_UNBLOCK_DELETED ### Detailed description of code changes blocked.c: 1. Both module and stream functions are called whether the key exists or not, regardless of its type. We do that in order to allow modules/stream to unblock the client in case the key is no longer present or has changed type (the behavior for streams didn't change, just code that moved into serveClientsBlockedOnStreamKey) 2. Make sure afterCommand is called in serveClientsBlockedOnKeyByModule, in order to propagate actions from moduleTryServeClientBlockedOnKey. 3. handleClientsBlockedOnKeys: call propagatePendingCommands directly after lookupKeyReadWithFlags to prevent a possible lazy-expire DEL from being mixed with any command propagated by the preceding functions. 4. blockForKeys: Caller can specifiy that it wants to be awakened if key is deleted. Minor optimizations (use dictAddRaw). 5. signalKeyAsReady became signalKeyAsReadyLogic which can take a boolean in case the key is deleted. It will only signal if there's at least one client that awaits key deletion (to save calls to handleClientsBlockedOnKeys). Minor optimizations (use dictAddRaw) db.c: 1. scanDatabaseForDeletedStreams is now scanDatabaseForDeletedKeys and will signalKeyAsReady for any key that was removed from the database or changed type. It is the responsibility of the code in blocked.c to ignore or act on deleted/type-changed keys. 2. Use the new signalDeletedKeyAsReady where needed blockedonkey.c + tcl: 1. Added test of new capabilities (FSL.BPOPGT now requires the key to exist in order to work)
Diffstat (limited to 'src/server.c')
-rw-r--r--src/server.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/server.c b/src/server.c
index 4962b4fba..844ed4111 100644
--- a/src/server.c
+++ b/src/server.c
@@ -2495,6 +2495,7 @@ void initServer(void) {
server.db[j].expires = dictCreate(&dbExpiresDictType);
server.db[j].expires_cursor = 0;
server.db[j].blocking_keys = dictCreate(&keylistDictType);
+ server.db[j].blocking_keys_unblock_on_nokey = dictCreate(&objectKeyPointerValueDictType);
server.db[j].ready_keys = dictCreate(&objectKeyPointerValueDictType);
server.db[j].watched_keys = dictCreate(&keylistDictType);
server.db[j].id = j;