2022-01-20 07:05:53 +00:00
|
|
|
/* define macros for having usleep */
|
|
|
|
#define _BSD_SOURCE
|
|
|
|
#define _DEFAULT_SOURCE
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
#include "redismodule.h"
|
|
|
|
#include <assert.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <pthread.h>
|
2022-06-21 07:01:13 +00:00
|
|
|
#include <strings.h>
|
2020-09-09 13:01:16 +00:00
|
|
|
|
|
|
|
#define UNUSED(V) ((void) V)
|
|
|
|
|
2022-01-20 07:05:53 +00:00
|
|
|
/* used to test processing events during slow bg operation */
|
|
|
|
static volatile int g_slow_bg_operation = 0;
|
|
|
|
static volatile int g_is_in_slow_bg_operation = 0;
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
void *sub_worker(void *arg) {
|
|
|
|
// Get Redis module context
|
|
|
|
RedisModuleCtx *ctx = (RedisModuleCtx *)arg;
|
|
|
|
|
|
|
|
// Try acquiring GIL
|
|
|
|
int res = RedisModule_ThreadSafeContextTryLock(ctx);
|
|
|
|
|
|
|
|
// GIL is already taken by the calling thread expecting to fail.
|
|
|
|
assert(res != REDISMODULE_OK);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void *worker(void *arg) {
|
|
|
|
// Retrieve blocked client
|
|
|
|
RedisModuleBlockedClient *bc = (RedisModuleBlockedClient *)arg;
|
|
|
|
|
|
|
|
// Get Redis module context
|
|
|
|
RedisModuleCtx *ctx = RedisModule_GetThreadSafeContext(bc);
|
|
|
|
|
|
|
|
// Acquire GIL
|
|
|
|
RedisModule_ThreadSafeContextLock(ctx);
|
|
|
|
|
|
|
|
// Create another thread which will try to acquire the GIL
|
|
|
|
pthread_t tid;
|
|
|
|
int res = pthread_create(&tid, NULL, sub_worker, ctx);
|
|
|
|
assert(res == 0);
|
|
|
|
|
|
|
|
// Wait for thread
|
|
|
|
pthread_join(tid, NULL);
|
|
|
|
|
|
|
|
// Release GIL
|
|
|
|
RedisModule_ThreadSafeContextUnlock(ctx);
|
|
|
|
|
|
|
|
// Reply to client
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "OK");
|
|
|
|
|
|
|
|
// Unblock client
|
|
|
|
RedisModule_UnblockClient(bc, NULL);
|
|
|
|
|
2020-09-10 07:22:16 +00:00
|
|
|
// Free the Redis module context
|
|
|
|
RedisModule_FreeThreadSafeContext(ctx);
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int acquire_gil(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
|
|
|
|
{
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
2020-10-11 14:21:58 +00:00
|
|
|
int flags = RedisModule_GetContextFlags(ctx);
|
|
|
|
int allFlags = RedisModule_GetContextFlagsAll();
|
|
|
|
if ((allFlags & REDISMODULE_CTX_FLAGS_MULTI) &&
|
|
|
|
(flags & REDISMODULE_CTX_FLAGS_MULTI)) {
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "Blocked client is not supported inside multi");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 16:58:55 +00:00
|
|
|
if ((allFlags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING) &&
|
|
|
|
(flags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING)) {
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "Blocked client is not allowed");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
/* This command handler tries to acquire the GIL twice
|
|
|
|
* once in the worker thread using "RedisModule_ThreadSafeContextLock"
|
|
|
|
* second in the sub-worker thread
|
|
|
|
* using "RedisModule_ThreadSafeContextTryLock"
|
|
|
|
* as the GIL is already locked. */
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
|
|
|
|
pthread_t tid;
|
|
|
|
int res = pthread_create(&tid, NULL, worker, bc);
|
|
|
|
assert(res == 0);
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2020-12-08 14:41:20 +00:00
|
|
|
typedef struct {
|
|
|
|
RedisModuleString **argv;
|
|
|
|
int argc;
|
|
|
|
RedisModuleBlockedClient *bc;
|
|
|
|
} bg_call_data;
|
|
|
|
|
|
|
|
void *bg_call_worker(void *arg) {
|
|
|
|
bg_call_data *bg = arg;
|
|
|
|
|
|
|
|
// Get Redis module context
|
|
|
|
RedisModuleCtx *ctx = RedisModule_GetThreadSafeContext(bg->bc);
|
|
|
|
|
|
|
|
// Acquire GIL
|
|
|
|
RedisModule_ThreadSafeContextLock(ctx);
|
|
|
|
|
2022-01-20 07:05:53 +00:00
|
|
|
// Test slow operation yielding
|
|
|
|
if (g_slow_bg_operation) {
|
|
|
|
g_is_in_slow_bg_operation = 1;
|
|
|
|
while (g_slow_bg_operation) {
|
|
|
|
RedisModule_Yield(ctx, REDISMODULE_YIELD_FLAG_CLIENTS, "Slow module operation");
|
|
|
|
usleep(1000);
|
|
|
|
}
|
|
|
|
g_is_in_slow_bg_operation = 0;
|
|
|
|
}
|
|
|
|
|
2020-12-08 14:41:20 +00:00
|
|
|
// Call the command
|
2022-06-21 07:01:13 +00:00
|
|
|
const char *module_cmd = RedisModule_StringPtrLen(bg->argv[0], NULL);
|
|
|
|
int cmd_pos = 1;
|
|
|
|
RedisModuleString *format_redis_str = RedisModule_CreateString(NULL, "v", 1);
|
|
|
|
if (!strcasecmp(module_cmd, "do_bg_rm_call_format")) {
|
|
|
|
cmd_pos = 2;
|
|
|
|
size_t format_len;
|
|
|
|
const char *format = RedisModule_StringPtrLen(bg->argv[1], &format_len);
|
|
|
|
RedisModule_StringAppendBuffer(NULL, format_redis_str, format, format_len);
|
|
|
|
RedisModule_StringAppendBuffer(NULL, format_redis_str, "E", 1);
|
|
|
|
}
|
|
|
|
const char *format = RedisModule_StringPtrLen(format_redis_str, NULL);
|
|
|
|
const char *cmd = RedisModule_StringPtrLen(bg->argv[cmd_pos], NULL);
|
|
|
|
RedisModuleCallReply *rep = RedisModule_Call(ctx, cmd, format, bg->argv + cmd_pos + 1, bg->argc - cmd_pos - 1);
|
|
|
|
RedisModule_FreeString(NULL, format_redis_str);
|
2020-12-08 14:41:20 +00:00
|
|
|
|
|
|
|
// Release GIL
|
|
|
|
RedisModule_ThreadSafeContextUnlock(ctx);
|
|
|
|
|
|
|
|
// Reply to client
|
|
|
|
if (!rep) {
|
|
|
|
RedisModule_ReplyWithError(ctx, "NULL reply returned");
|
|
|
|
} else {
|
|
|
|
RedisModule_ReplyWithCallReply(ctx, rep);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unblock client
|
|
|
|
RedisModule_UnblockClient(bg->bc, NULL);
|
|
|
|
|
|
|
|
/* Free the arguments */
|
|
|
|
for (int i=0; i<bg->argc; i++)
|
|
|
|
RedisModule_FreeString(ctx, bg->argv[i]);
|
|
|
|
RedisModule_Free(bg->argv);
|
|
|
|
RedisModule_Free(bg);
|
|
|
|
|
|
|
|
// Free the Redis module context
|
|
|
|
RedisModule_FreeThreadSafeContext(ctx);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int do_bg_rm_call(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
|
|
|
|
{
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
/* Make sure we're not trying to block a client when we shouldn't */
|
|
|
|
int flags = RedisModule_GetContextFlags(ctx);
|
|
|
|
int allFlags = RedisModule_GetContextFlagsAll();
|
|
|
|
if ((allFlags & REDISMODULE_CTX_FLAGS_MULTI) &&
|
|
|
|
(flags & REDISMODULE_CTX_FLAGS_MULTI)) {
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "Blocked client is not supported inside multi");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
if ((allFlags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING) &&
|
|
|
|
(flags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING)) {
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "Blocked client is not allowed");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Make a copy of the arguments and pass them to the thread. */
|
|
|
|
bg_call_data *bg = RedisModule_Alloc(sizeof(bg_call_data));
|
|
|
|
bg->argv = RedisModule_Alloc(sizeof(RedisModuleString*)*argc);
|
|
|
|
bg->argc = argc;
|
|
|
|
for (int i=0; i<argc; i++)
|
|
|
|
bg->argv[i] = RedisModule_HoldString(ctx, argv[i]);
|
|
|
|
|
|
|
|
/* Block the client */
|
|
|
|
bg->bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
|
|
|
|
/* Start a thread to handle the request */
|
|
|
|
pthread_t tid;
|
|
|
|
int res = pthread_create(&tid, NULL, bg_call_worker, bg);
|
|
|
|
assert(res == 0);
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 16:58:55 +00:00
|
|
|
int do_rm_call(RedisModuleCtx *ctx, RedisModuleString **argv, int argc){
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
if(argc < 2){
|
|
|
|
return RedisModule_WrongArity(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* cmd = RedisModule_StringPtrLen(argv[1], NULL);
|
|
|
|
|
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 12:13:28 +00:00
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, cmd, "Ev", argv + 2, argc - 2);
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 16:58:55 +00:00
|
|
|
if(!rep){
|
|
|
|
RedisModule_ReplyWithError(ctx, "NULL reply returned");
|
|
|
|
}else{
|
|
|
|
RedisModule_ReplyWithCallReply(ctx, rep);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2021-10-21 11:01:10 +00:00
|
|
|
/* simulate a blocked client replying to a thread safe context without creating a thread */
|
|
|
|
int do_fake_bg_true(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
RedisModuleCtx *bctx = RedisModule_GetThreadSafeContext(bc);
|
|
|
|
|
|
|
|
RedisModule_ReplyWithBool(bctx, 1);
|
|
|
|
|
|
|
|
RedisModule_FreeThreadSafeContext(bctx);
|
|
|
|
RedisModule_UnblockClient(bc, NULL);
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 16:58:55 +00:00
|
|
|
|
2022-01-20 07:05:53 +00:00
|
|
|
|
|
|
|
/* this flag is used to work with busy commands, that might take a while
|
|
|
|
* and ability to stop the busy work with a different command*/
|
|
|
|
static volatile int abort_flag = 0;
|
|
|
|
|
|
|
|
int slow_fg_command(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
if (argc != 2) {
|
|
|
|
RedisModule_WrongArity(ctx);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
long long block_time = 0;
|
|
|
|
if (RedisModule_StringToLongLong(argv[1], &block_time) != REDISMODULE_OK) {
|
|
|
|
RedisModule_ReplyWithError(ctx, "Invalid integer value");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t start_time = RedisModule_MonotonicMicroseconds();
|
|
|
|
/* when not blocking indefinitely, we don't process client commands in this test. */
|
|
|
|
int yield_flags = block_time? REDISMODULE_YIELD_FLAG_NONE: REDISMODULE_YIELD_FLAG_CLIENTS;
|
|
|
|
while (!abort_flag) {
|
|
|
|
RedisModule_Yield(ctx, yield_flags, "Slow module operation");
|
|
|
|
usleep(1000);
|
|
|
|
if (block_time && RedisModule_MonotonicMicroseconds() - start_time > (uint64_t)block_time)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
abort_flag = 0;
|
|
|
|
RedisModule_ReplyWithLongLong(ctx, 1);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
int stop_slow_fg_command(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
REDISMODULE_NOT_USED(argv);
|
|
|
|
REDISMODULE_NOT_USED(argc);
|
|
|
|
abort_flag = 1;
|
|
|
|
RedisModule_ReplyWithLongLong(ctx, 1);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* used to enable or disable slow operation in do_bg_rm_call */
|
|
|
|
static int set_slow_bg_operation(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
if (argc != 2) {
|
|
|
|
RedisModule_WrongArity(ctx);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
long long ll;
|
|
|
|
if (RedisModule_StringToLongLong(argv[1], &ll) != REDISMODULE_OK) {
|
|
|
|
RedisModule_ReplyWithError(ctx, "Invalid integer value");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
g_slow_bg_operation = ll;
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "OK");
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* used to test if we reached the slow operation in do_bg_rm_call */
|
|
|
|
static int is_in_slow_bg_operation(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
UNUSED(argv);
|
|
|
|
if (argc != 1) {
|
|
|
|
RedisModule_WrongArity(ctx);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
RedisModule_ReplyWithLongLong(ctx, g_is_in_slow_bg_operation);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
REDISMODULE_NOT_USED(argv);
|
|
|
|
REDISMODULE_NOT_USED(argc);
|
|
|
|
|
|
|
|
if (RedisModule_Init(ctx, "blockedclient", 1, REDISMODULE_APIVER_1)== REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "acquire_gil", acquire_gil, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2021-11-28 09:26:28 +00:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call", do_rm_call,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 16:58:55 +00:00
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2020-12-08 14:41:20 +00:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_bg_rm_call", do_bg_rm_call, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2022-06-21 07:01:13 +00:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_bg_rm_call_format", do_bg_rm_call, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2021-10-21 11:01:10 +00:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_fake_bg_true", do_fake_bg_true, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2022-01-20 07:05:53 +00:00
|
|
|
if (RedisModule_CreateCommand(ctx, "slow_fg_command", slow_fg_command,"", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "stop_slow_fg_command", stop_slow_fg_command,"allow-busy", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "set_slow_bg_operation", set_slow_bg_operation, "allow-busy", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "is_in_slow_bg_operation", is_in_slow_bg_operation, "allow-busy", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2020-09-09 13:01:16 +00:00
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|