2022-01-20 02:05:53 -05:00
|
|
|
/* define macros for having usleep */
|
|
|
|
#define _BSD_SOURCE
|
|
|
|
#define _DEFAULT_SOURCE
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2020-09-09 09:01:16 -04:00
|
|
|
#include "redismodule.h"
|
|
|
|
#include <assert.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <pthread.h>
|
2022-06-21 03:01:13 -04:00
|
|
|
#include <strings.h>
|
2020-09-09 09:01:16 -04:00
|
|
|
|
|
|
|
#define UNUSED(V) ((void) V)
|
|
|
|
|
2022-01-20 02:05:53 -05: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 09:01:16 -04: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 03:22:16 -04:00
|
|
|
// Free the Redis module context
|
|
|
|
RedisModule_FreeThreadSafeContext(ctx);
|
|
|
|
|
2020-09-09 09:01:16 -04:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int acquire_gil(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
|
|
|
|
{
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
2020-10-11 10:21:58 -04: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 11:58:55 -05: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 09:01:16 -04: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 09:41:20 -05:00
|
|
|
typedef struct {
|
|
|
|
RedisModuleString **argv;
|
|
|
|
int argc;
|
|
|
|
RedisModuleBlockedClient *bc;
|
|
|
|
} bg_call_data;
|
|
|
|
|
|
|
|
void *bg_call_worker(void *arg) {
|
|
|
|
bg_call_data *bg = arg;
|
Fix race condition issues between the main thread and module threads (#12817)
Fix #12785 and other race condition issues.
See the following isolated comments.
The following report was obtained using SANITIZER thread.
```sh
make SANITIZER=thread
./runtest-moduleapi --config io-threads 4 --config io-threads-do-reads yes --accurate
```
1. Fixed thread-safe issue in RM_UnblockClient()
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1831181220
* When blocking a client in a module using `RM_BlockClientOnKeys()` or
`RM_BlockClientOnKeysWithFlags()`
with a timeout_callback, calling RM_UnblockClient() in module threads
can lead to race conditions
in `updateStatsOnUnblock()`.
- Introduced:
Version: 6.2
PR: #7491
- Touch:
`server.stat_numcommands`, `cmd->latency_histogram`, `server.slowlog`,
and `server.latency_events`
- Harm Level: High
Potentially corrupts the memory data of `cmd->latency_histogram`,
`server.slowlog`, and `server.latency_events`
- Solution:
Differentiate whether the call to moduleBlockedClientTimedOut() comes
from the module or the main thread.
Since we can't know if RM_UnblockClient() comes from module threads, we
always assume it does and
let `updateStatsOnUnblock()` asynchronously update the unblock status.
* When error reply is called in timeout_callback(), ctx is not
thread-safe, eventually lead to race conditions in `afterErrorReply`.
- Introduced:
Version: 6.2
PR: #8217
- Touch
`server.stat_total_error_replies`, `server.errors`,
- Harm Level: High
Potentially corrupts the memory data of `server.errors`
- Solution:
Make the ctx in `timeout_callback()` with `REDISMODULE_CTX_THREAD_SAFE`,
and asynchronously reply errors to the client.
2. Made RM_Reply*() family API thread-safe
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408707239
Call chain: `RM_Reply*()` -> `_addReplyToBufferOrList()` -> touch
server.current_client
- Introduced:
Version: 7.2.0
PR: #12326
- Harm Level: None
Since the module fake client won't have the `CLIENT_PUSHING` flag, even
if we touch server.current_client,
we can still exit after `c->flags & CLIENT_PUSHING`.
- Solution
Checking `c->flags & CLIENT_PUSHING` earlier.
3. Made freeClient() thread-safe
Fix #12785
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/3fcf959e609e850a114d4016843e4c991066ebac
- Harm Level: Moderate
* Trigger assertion
It happens when the module thread calls freeClient while the io-thread
is in progress,
which just triggers an assertion, and doesn't make any race condiaions.
* Touch `server.current_client`, `server.stat_clients_type_memory`, and
`clientMemUsageBucket->clients`.
It happens between the main thread and the module threads, may cause
data corruption.
1. Error reset `server.current_client` to NULL, but theoretically this
won't happen,
because the module has already reset `server.current_client` to old
value before entering freeClient.
2. corrupts `clientMemUsageBucket->clients` in
updateClientMemUsageAndBucket().
3. Causes server.stat_clients_type_memory memory statistics to be
inaccurate.
- Solution:
* No longer counts memory usage on fake clients, to avoid updating
`server.stat_clients_type_memory` in freeClient.
* No longer resetting `server.current_client` in unlinkClient, because
the fake client won't be evicted or disconnected in the mid of the
process.
* Judgment assertion `io_threads_op == IO_THREADS_OP_IDLE` only if c is
not a fake client.
4. Fixed free client args without GIL
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408706695
When freeing retained strings in the module thread (refcount decr), or
using them in some way (refcount incr), we should do so while holding
the GIL,
otherwise, they might be simultaneously freed while the main thread is
processing the unblock client state.
- Introduced:
Version: 6.2.0
PR: #8141
- Harm Level: Low
Trigger assertion or double free or memory leak.
- Solution:
Documenting that module API users need to ensure any access to these
retained strings is done with the GIL locked
5. Fix adding fake client to server.clients_pending_write
It will incorrectly log the memory usage for the fake client.
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1851899163
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/9b01b64430fbc1487429144d2e4e72a4a7fd9db2
- Harm Level: None
Only result in NOP
- Solution:
* Don't add fake client into server.clients_pending_write
* Add c->conn assertion for updateClientMemUsageAndBucket() and
updateClientMemoryUsage() to avoid same
issue in the future.
So now it will be the responsibility of the caller of both of them to
avoid passing in fake client.
6. Fix calling RM_BlockedClientMeasureTimeStart() and
RM_BlockedClientMeasureTimeEnd() without GIL
- Introduced:
Version: 6.2
PR: #7491
- Harm Level: Low
Causes inaccuracies in command latency histogram and slow logs, but does
not corrupt memory.
- Solution:
Module API users, if know that non-thread-safe APIs will be used in
multi-threading, need to take responsibility for protecting them with
their own locks instead of the GIL, as using the GIL is too expensive.
### Other issue
1. RM_Yield is not thread-safe, fixed via #12905.
### Summarize
1. Fix thread-safe issues for `RM_UnblockClient()`, `freeClient()` and
`RM_Yield`, potentially preventing memory corruption, data disorder, or
assertion.
2. Updated docs and module test to clarify module API users'
responsibility for locking non-thread-safe APIs in multi-threading, such
as RM_BlockedClientMeasureTimeStart/End(), RM_FreeString(),
RM_RetainString(), and RM_HoldString().
### About backpot to 7.2
1. The implement of (1) is not too satisfying, would like to get more
eyes.
2. (2), (3) can be safely for backport
3. (4), (6) just modifying the module tests and updating the
documentation, no need for a backpot.
4. (5) is harmless, no need for a backpot.
---------
Co-authored-by: Oran Agra <oran@redislabs.com>
2024-01-19 08:12:49 -05:00
|
|
|
RedisModuleBlockedClient *bc = bg->bc;
|
2020-12-08 09:41:20 -05:00
|
|
|
|
|
|
|
// Get Redis module context
|
|
|
|
RedisModuleCtx *ctx = RedisModule_GetThreadSafeContext(bg->bc);
|
|
|
|
|
|
|
|
// Acquire GIL
|
|
|
|
RedisModule_ThreadSafeContextLock(ctx);
|
|
|
|
|
2022-01-20 02:05:53 -05: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 09:41:20 -05:00
|
|
|
// Call the command
|
2022-06-21 03:01:13 -04: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 09:41:20 -05:00
|
|
|
|
Fix race condition issues between the main thread and module threads (#12817)
Fix #12785 and other race condition issues.
See the following isolated comments.
The following report was obtained using SANITIZER thread.
```sh
make SANITIZER=thread
./runtest-moduleapi --config io-threads 4 --config io-threads-do-reads yes --accurate
```
1. Fixed thread-safe issue in RM_UnblockClient()
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1831181220
* When blocking a client in a module using `RM_BlockClientOnKeys()` or
`RM_BlockClientOnKeysWithFlags()`
with a timeout_callback, calling RM_UnblockClient() in module threads
can lead to race conditions
in `updateStatsOnUnblock()`.
- Introduced:
Version: 6.2
PR: #7491
- Touch:
`server.stat_numcommands`, `cmd->latency_histogram`, `server.slowlog`,
and `server.latency_events`
- Harm Level: High
Potentially corrupts the memory data of `cmd->latency_histogram`,
`server.slowlog`, and `server.latency_events`
- Solution:
Differentiate whether the call to moduleBlockedClientTimedOut() comes
from the module or the main thread.
Since we can't know if RM_UnblockClient() comes from module threads, we
always assume it does and
let `updateStatsOnUnblock()` asynchronously update the unblock status.
* When error reply is called in timeout_callback(), ctx is not
thread-safe, eventually lead to race conditions in `afterErrorReply`.
- Introduced:
Version: 6.2
PR: #8217
- Touch
`server.stat_total_error_replies`, `server.errors`,
- Harm Level: High
Potentially corrupts the memory data of `server.errors`
- Solution:
Make the ctx in `timeout_callback()` with `REDISMODULE_CTX_THREAD_SAFE`,
and asynchronously reply errors to the client.
2. Made RM_Reply*() family API thread-safe
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408707239
Call chain: `RM_Reply*()` -> `_addReplyToBufferOrList()` -> touch
server.current_client
- Introduced:
Version: 7.2.0
PR: #12326
- Harm Level: None
Since the module fake client won't have the `CLIENT_PUSHING` flag, even
if we touch server.current_client,
we can still exit after `c->flags & CLIENT_PUSHING`.
- Solution
Checking `c->flags & CLIENT_PUSHING` earlier.
3. Made freeClient() thread-safe
Fix #12785
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/3fcf959e609e850a114d4016843e4c991066ebac
- Harm Level: Moderate
* Trigger assertion
It happens when the module thread calls freeClient while the io-thread
is in progress,
which just triggers an assertion, and doesn't make any race condiaions.
* Touch `server.current_client`, `server.stat_clients_type_memory`, and
`clientMemUsageBucket->clients`.
It happens between the main thread and the module threads, may cause
data corruption.
1. Error reset `server.current_client` to NULL, but theoretically this
won't happen,
because the module has already reset `server.current_client` to old
value before entering freeClient.
2. corrupts `clientMemUsageBucket->clients` in
updateClientMemUsageAndBucket().
3. Causes server.stat_clients_type_memory memory statistics to be
inaccurate.
- Solution:
* No longer counts memory usage on fake clients, to avoid updating
`server.stat_clients_type_memory` in freeClient.
* No longer resetting `server.current_client` in unlinkClient, because
the fake client won't be evicted or disconnected in the mid of the
process.
* Judgment assertion `io_threads_op == IO_THREADS_OP_IDLE` only if c is
not a fake client.
4. Fixed free client args without GIL
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408706695
When freeing retained strings in the module thread (refcount decr), or
using them in some way (refcount incr), we should do so while holding
the GIL,
otherwise, they might be simultaneously freed while the main thread is
processing the unblock client state.
- Introduced:
Version: 6.2.0
PR: #8141
- Harm Level: Low
Trigger assertion or double free or memory leak.
- Solution:
Documenting that module API users need to ensure any access to these
retained strings is done with the GIL locked
5. Fix adding fake client to server.clients_pending_write
It will incorrectly log the memory usage for the fake client.
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1851899163
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/9b01b64430fbc1487429144d2e4e72a4a7fd9db2
- Harm Level: None
Only result in NOP
- Solution:
* Don't add fake client into server.clients_pending_write
* Add c->conn assertion for updateClientMemUsageAndBucket() and
updateClientMemoryUsage() to avoid same
issue in the future.
So now it will be the responsibility of the caller of both of them to
avoid passing in fake client.
6. Fix calling RM_BlockedClientMeasureTimeStart() and
RM_BlockedClientMeasureTimeEnd() without GIL
- Introduced:
Version: 6.2
PR: #7491
- Harm Level: Low
Causes inaccuracies in command latency histogram and slow logs, but does
not corrupt memory.
- Solution:
Module API users, if know that non-thread-safe APIs will be used in
multi-threading, need to take responsibility for protecting them with
their own locks instead of the GIL, as using the GIL is too expensive.
### Other issue
1. RM_Yield is not thread-safe, fixed via #12905.
### Summarize
1. Fix thread-safe issues for `RM_UnblockClient()`, `freeClient()` and
`RM_Yield`, potentially preventing memory corruption, data disorder, or
assertion.
2. Updated docs and module test to clarify module API users'
responsibility for locking non-thread-safe APIs in multi-threading, such
as RM_BlockedClientMeasureTimeStart/End(), RM_FreeString(),
RM_RetainString(), and RM_HoldString().
### About backpot to 7.2
1. The implement of (1) is not too satisfying, would like to get more
eyes.
2. (2), (3) can be safely for backport
3. (4), (6) just modifying the module tests and updating the
documentation, no need for a backpot.
4. (5) is harmless, no need for a backpot.
---------
Co-authored-by: Oran Agra <oran@redislabs.com>
2024-01-19 08:12:49 -05:00
|
|
|
/* Free the arguments within GIL to prevent simultaneous freeing in main thread. */
|
|
|
|
for (int i=0; i<bg->argc; i++)
|
|
|
|
RedisModule_FreeString(ctx, bg->argv[i]);
|
|
|
|
RedisModule_Free(bg->argv);
|
|
|
|
RedisModule_Free(bg);
|
|
|
|
|
2020-12-08 09:41:20 -05: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
|
Fix race condition issues between the main thread and module threads (#12817)
Fix #12785 and other race condition issues.
See the following isolated comments.
The following report was obtained using SANITIZER thread.
```sh
make SANITIZER=thread
./runtest-moduleapi --config io-threads 4 --config io-threads-do-reads yes --accurate
```
1. Fixed thread-safe issue in RM_UnblockClient()
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1831181220
* When blocking a client in a module using `RM_BlockClientOnKeys()` or
`RM_BlockClientOnKeysWithFlags()`
with a timeout_callback, calling RM_UnblockClient() in module threads
can lead to race conditions
in `updateStatsOnUnblock()`.
- Introduced:
Version: 6.2
PR: #7491
- Touch:
`server.stat_numcommands`, `cmd->latency_histogram`, `server.slowlog`,
and `server.latency_events`
- Harm Level: High
Potentially corrupts the memory data of `cmd->latency_histogram`,
`server.slowlog`, and `server.latency_events`
- Solution:
Differentiate whether the call to moduleBlockedClientTimedOut() comes
from the module or the main thread.
Since we can't know if RM_UnblockClient() comes from module threads, we
always assume it does and
let `updateStatsOnUnblock()` asynchronously update the unblock status.
* When error reply is called in timeout_callback(), ctx is not
thread-safe, eventually lead to race conditions in `afterErrorReply`.
- Introduced:
Version: 6.2
PR: #8217
- Touch
`server.stat_total_error_replies`, `server.errors`,
- Harm Level: High
Potentially corrupts the memory data of `server.errors`
- Solution:
Make the ctx in `timeout_callback()` with `REDISMODULE_CTX_THREAD_SAFE`,
and asynchronously reply errors to the client.
2. Made RM_Reply*() family API thread-safe
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408707239
Call chain: `RM_Reply*()` -> `_addReplyToBufferOrList()` -> touch
server.current_client
- Introduced:
Version: 7.2.0
PR: #12326
- Harm Level: None
Since the module fake client won't have the `CLIENT_PUSHING` flag, even
if we touch server.current_client,
we can still exit after `c->flags & CLIENT_PUSHING`.
- Solution
Checking `c->flags & CLIENT_PUSHING` earlier.
3. Made freeClient() thread-safe
Fix #12785
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/3fcf959e609e850a114d4016843e4c991066ebac
- Harm Level: Moderate
* Trigger assertion
It happens when the module thread calls freeClient while the io-thread
is in progress,
which just triggers an assertion, and doesn't make any race condiaions.
* Touch `server.current_client`, `server.stat_clients_type_memory`, and
`clientMemUsageBucket->clients`.
It happens between the main thread and the module threads, may cause
data corruption.
1. Error reset `server.current_client` to NULL, but theoretically this
won't happen,
because the module has already reset `server.current_client` to old
value before entering freeClient.
2. corrupts `clientMemUsageBucket->clients` in
updateClientMemUsageAndBucket().
3. Causes server.stat_clients_type_memory memory statistics to be
inaccurate.
- Solution:
* No longer counts memory usage on fake clients, to avoid updating
`server.stat_clients_type_memory` in freeClient.
* No longer resetting `server.current_client` in unlinkClient, because
the fake client won't be evicted or disconnected in the mid of the
process.
* Judgment assertion `io_threads_op == IO_THREADS_OP_IDLE` only if c is
not a fake client.
4. Fixed free client args without GIL
Related discussion:
https://github.com/redis/redis/pull/12817#discussion_r1408706695
When freeing retained strings in the module thread (refcount decr), or
using them in some way (refcount incr), we should do so while holding
the GIL,
otherwise, they might be simultaneously freed while the main thread is
processing the unblock client state.
- Introduced:
Version: 6.2.0
PR: #8141
- Harm Level: Low
Trigger assertion or double free or memory leak.
- Solution:
Documenting that module API users need to ensure any access to these
retained strings is done with the GIL locked
5. Fix adding fake client to server.clients_pending_write
It will incorrectly log the memory usage for the fake client.
Related discussion:
https://github.com/redis/redis/pull/12817#issuecomment-1851899163
- Introduced:
Version: 4.0
Commit:
https://github.com/redis/redis/commit/9b01b64430fbc1487429144d2e4e72a4a7fd9db2
- Harm Level: None
Only result in NOP
- Solution:
* Don't add fake client into server.clients_pending_write
* Add c->conn assertion for updateClientMemUsageAndBucket() and
updateClientMemoryUsage() to avoid same
issue in the future.
So now it will be the responsibility of the caller of both of them to
avoid passing in fake client.
6. Fix calling RM_BlockedClientMeasureTimeStart() and
RM_BlockedClientMeasureTimeEnd() without GIL
- Introduced:
Version: 6.2
PR: #7491
- Harm Level: Low
Causes inaccuracies in command latency histogram and slow logs, but does
not corrupt memory.
- Solution:
Module API users, if know that non-thread-safe APIs will be used in
multi-threading, need to take responsibility for protecting them with
their own locks instead of the GIL, as using the GIL is too expensive.
### Other issue
1. RM_Yield is not thread-safe, fixed via #12905.
### Summarize
1. Fix thread-safe issues for `RM_UnblockClient()`, `freeClient()` and
`RM_Yield`, potentially preventing memory corruption, data disorder, or
assertion.
2. Updated docs and module test to clarify module API users'
responsibility for locking non-thread-safe APIs in multi-threading, such
as RM_BlockedClientMeasureTimeStart/End(), RM_FreeString(),
RM_RetainString(), and RM_HoldString().
### About backpot to 7.2
1. The implement of (1) is not too satisfying, would like to get more
eyes.
2. (2), (3) can be safely for backport
3. (4), (6) just modifying the module tests and updating the
documentation, no need for a backpot.
4. (5) is harmless, no need for a backpot.
---------
Co-authored-by: Oran Agra <oran@redislabs.com>
2024-01-19 08:12:49 -05:00
|
|
|
RedisModule_UnblockClient(bc, NULL);
|
2020-12-08 09:41:20 -05:00
|
|
|
|
|
|
|
// 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 11:58:55 -05: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 08:13:28 -04: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 11:58:55 -05:00
|
|
|
if(!rep){
|
|
|
|
RedisModule_ReplyWithError(ctx, "NULL reply returned");
|
|
|
|
}else{
|
|
|
|
RedisModule_ReplyWithCallReply(ctx, rep);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
Support for RM_Call on blocking commands (#11568)
Allow running blocking commands from within a module using `RM_Call`.
Today, when `RM_Call` is used, the fake client that is used to run command
is marked with `CLIENT_DENY_BLOCKING` flag. This flag tells the command
that it is not allowed to block the client and in case it needs to block, it must
fallback to some alternative (either return error or perform some default behavior).
For example, `BLPOP` fallback to simple `LPOP` if it is not allowed to block.
All the commands must respect the `CLIENT_DENY_BLOCKING` flag (including
module commands). When the command invocation finished, Redis asserts that
the client was not blocked.
This PR introduces the ability to call blocking command using `RM_Call` by
passing a callback that will be called when the client will get unblocked.
In order to do that, the user must explicitly say that he allow to perform blocking
command by passing a new format specifier argument, `K`, to the `RM_Call`
function. This new flag will tell Redis that it is allow to run blocking command
and block the client. In case the command got blocked, Redis will return a new
type of call reply (`REDISMODULE_REPLY_PROMISE`). This call reply indicates
that the command got blocked and the user can set the on_unblocked handler using
`RM_CallReplyPromiseSetUnblockHandler`.
When clients gets unblocked, it eventually reaches `processUnblockedClients` function.
This is where we check if the client is a fake module client and if it is, we call the unblock
callback instead of performing the usual unblock operations.
**Notice**: `RM_CallReplyPromiseSetUnblockHandler` must be called atomically
along side the command invocation (without releasing the Redis lock in between).
In addition, unlike other CallReply types, the promise call reply must be released
by the module when the Redis GIL is acquired.
The module can abort the execution on the blocking command (if it was not yet
executed) using `RM_CallReplyPromiseAbort`. the API will return `REDISMODULE_OK`
on success and `REDISMODULE_ERR` if the operation is already executed.
**Notice** that in case of misbehave module, Abort might finished successfully but the
operation will not really be aborted. This can only happened if the module do not respect
the disconnect callback of the blocked client.
For pure Redis commands this can not happened.
### Atomicity Guarantees
The API promise that the unblock handler will run atomically as an execution unit.
This means that all the operation performed on the unblock handler will be wrapped
with a multi exec transaction when replicated to the replica and AOF.
The API **do not** grantee any other atomicity properties such as when the unblock
handler will be called. This gives us the flexibility to strengthen the grantees (or not)
in the future if we will decide that we need a better guarantees.
That said, the implementation **does** provide a better guarantees when performing
pure Redis blocking command like `BLPOP`. In this case the unblock handler will run
atomically with the operation that got unblocked (for example, in case of `BLPOP`, the
unblock handler will run atomically with the `LPOP` operation that run when the command
got unblocked). This is an implementation detail that might be change in the future and the
module writer should not count on that.
### Calling blocking commands while running on script mode (`S`)
`RM_Call` script mode (`S`) was introduced on #0372. It is used for usecases where the
command that was invoked on `RM_Call` comes from a user input and we want to make
sure the user will not run dangerous commands like `shutdown`. Some command, such
as `BLPOP`, are marked with `NO_SCRIPT` flag, which means they will not be allowed on
script mode. Those commands are marked with `NO_SCRIPT` just because they are
blocking commands and not because they are dangerous. Now that we can run blocking
commands on RM_Call, there is no real reason not to allow such commands on script mode.
The underline problem is that the `NO_SCRIPT` flag is abused to also mark some of the
blocking commands (notice that those commands know not to block the client if it is not
allowed to do so, and have a fallback logic to such cases. So even if those commands
were not marked with `NO_SCRIPT` flag, it would not harm Redis, and today we can
already run those commands within multi exec).
In addition, not all blocking commands are marked with `NO_SCRIPT` flag, for example
`blmpop` are not marked and can run from within a script.
Those facts shows that there are some ambiguity about the meaning of the `NO_SCRIPT`
flag, and its not fully clear where it should be use.
The PR suggest that blocking commands should not be marked with `NO_SCRIPT` flag,
those commands should handle `CLIENT_DENY_BLOCKING` flag and only block when
it's safe (like they already does today). To achieve that, the PR removes the `NO_SCRIPT`
flag from the following commands:
* `blmove`
* `blpop`
* `brpop`
* `brpoplpush`
* `bzpopmax`
* `bzpopmin`
* `wait`
This might be considered a breaking change as now, on scripts, instead of getting
`command is not allowed from script` error, the user will get some fallback behavior
base on the command implementation. That said, the change matches the behavior
of scripts and multi exec with respect to those commands and allow running them on
`RM_Call` even when script mode is used.
### Additional RedisModule API and changes
* `RM_BlockClientSetPrivateData` - Set private data on the blocked client without the
need to unblock the client. This allows up to set the promise CallReply as the private
data of the blocked client and abort it if the client gets disconnected.
* `RM_BlockClientGetPrivateData` - Return the current private data set on a blocked client.
We need it so we will have access to this private data on the disconnect callback.
* On RM_Call, the returned reply will be added to the auto memory context only if auto
memory is enabled, this allows us to keep the call reply for longer time then the context
lifetime and does not force an unneeded borrow relationship between the CallReply and
the RedisModuleContext.
2023-03-16 08:04:31 -04:00
|
|
|
static void rm_call_async_send_reply(RedisModuleCtx *ctx, RedisModuleCallReply *reply) {
|
|
|
|
RedisModule_ReplyWithCallReply(ctx, reply);
|
|
|
|
RedisModule_FreeCallReply(reply);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Called when the command that was blocked on 'RM_Call' gets unblocked
|
|
|
|
* and send the reply to the blocked client. */
|
|
|
|
static void rm_call_async_on_unblocked(RedisModuleCtx *ctx, RedisModuleCallReply *reply, void *private_data) {
|
|
|
|
UNUSED(ctx);
|
|
|
|
RedisModuleBlockedClient *bc = private_data;
|
|
|
|
RedisModuleCtx *bctx = RedisModule_GetThreadSafeContext(bc);
|
|
|
|
rm_call_async_send_reply(bctx, reply);
|
|
|
|
RedisModule_FreeThreadSafeContext(bctx);
|
|
|
|
RedisModule_UnblockClient(bc, RedisModule_BlockClientGetPrivateData(bc));
|
|
|
|
}
|
|
|
|
|
|
|
|
int do_rm_call_async_fire_and_forget(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);
|
|
|
|
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, cmd, "!KEv", argv + 2, argc - 2);
|
|
|
|
|
|
|
|
if(RedisModule_CallReplyType(rep) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
RedisModule_ReplyWithCallReply(ctx, rep);
|
|
|
|
} else {
|
|
|
|
RedisModule_ReplyWithSimpleString(ctx, "Blocked");
|
|
|
|
}
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_rm_call_async_free_pd(RedisModuleCtx * ctx, void *pd) {
|
|
|
|
UNUSED(ctx);
|
|
|
|
RedisModule_FreeCallReply(pd);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_rm_call_async_disconnect(RedisModuleCtx *ctx, struct RedisModuleBlockedClient *bc) {
|
|
|
|
UNUSED(ctx);
|
|
|
|
RedisModuleCallReply* rep = RedisModule_BlockClientGetPrivateData(bc);
|
|
|
|
RedisModule_CallReplyPromiseAbort(rep, NULL);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
RedisModule_AbortBlock(bc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback for do_rm_call_async / do_rm_call_async_script_mode
|
|
|
|
* Gets the command to invoke as the first argument to the command and runs it,
|
|
|
|
* passing the rest of the arguments to the command invocation.
|
|
|
|
* If the command got blocked, blocks the client and unblock it when the command gets unblocked,
|
|
|
|
* this allows check the K (allow blocking) argument to RM_Call.
|
|
|
|
*/
|
|
|
|
int do_rm_call_async(RedisModuleCtx *ctx, RedisModuleString **argv, int argc){
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
if(argc < 2){
|
|
|
|
return RedisModule_WrongArity(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t format_len = 0;
|
|
|
|
char format[6] = {0};
|
|
|
|
|
|
|
|
if (!(RedisModule_GetContextFlags(ctx) & REDISMODULE_CTX_FLAGS_DENY_BLOCKING)) {
|
|
|
|
/* We are allowed to block the client so we can allow RM_Call to also block us */
|
|
|
|
format[format_len++] = 'K';
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* invoked_cmd = RedisModule_StringPtrLen(argv[0], NULL);
|
|
|
|
if (strcasecmp(invoked_cmd, "do_rm_call_async_script_mode") == 0) {
|
|
|
|
format[format_len++] = 'S';
|
|
|
|
}
|
|
|
|
|
|
|
|
format[format_len++] = 'E';
|
|
|
|
format[format_len++] = 'v';
|
|
|
|
if (strcasecmp(invoked_cmd, "do_rm_call_async_no_replicate") != 0) {
|
|
|
|
/* Notice, without the '!' flag we will have inconsistency between master and replica.
|
|
|
|
* This is used only to check '!' flag correctness on blocked commands. */
|
|
|
|
format[format_len++] = '!';
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* cmd = RedisModule_StringPtrLen(argv[1], NULL);
|
|
|
|
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, cmd, format, argv + 2, argc - 2);
|
|
|
|
|
|
|
|
if(RedisModule_CallReplyType(rep) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
rm_call_async_send_reply(ctx, rep);
|
|
|
|
} else {
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, do_rm_call_async_free_pd, 0);
|
|
|
|
RedisModule_SetDisconnectCallback(bc, do_rm_call_async_disconnect);
|
|
|
|
RedisModule_BlockClientSetPrivateData(bc, rep);
|
|
|
|
RedisModule_CallReplyPromiseSetUnblockHandler(rep, rm_call_async_on_unblocked, bc);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2023-06-25 07:12:27 -04:00
|
|
|
typedef struct ThreadedAsyncRMCallCtx{
|
|
|
|
RedisModuleBlockedClient *bc;
|
|
|
|
RedisModuleCallReply *reply;
|
|
|
|
} ThreadedAsyncRMCallCtx;
|
|
|
|
|
|
|
|
void *send_async_reply(void *arg) {
|
|
|
|
ThreadedAsyncRMCallCtx *ta_rm_call_ctx = arg;
|
|
|
|
rm_call_async_on_unblocked(NULL, ta_rm_call_ctx->reply, ta_rm_call_ctx->bc);
|
|
|
|
RedisModule_Free(ta_rm_call_ctx);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Called when the command that was blocked on 'RM_Call' gets unblocked
|
|
|
|
* and schedule a thread to send the reply to the blocked client. */
|
|
|
|
static void rm_call_async_reply_on_thread(RedisModuleCtx *ctx, RedisModuleCallReply *reply, void *private_data) {
|
|
|
|
UNUSED(ctx);
|
|
|
|
ThreadedAsyncRMCallCtx *ta_rm_call_ctx = RedisModule_Alloc(sizeof(*ta_rm_call_ctx));
|
|
|
|
ta_rm_call_ctx->bc = private_data;
|
|
|
|
ta_rm_call_ctx->reply = reply;
|
|
|
|
pthread_t tid;
|
|
|
|
int res = pthread_create(&tid, NULL, send_async_reply, ta_rm_call_ctx);
|
|
|
|
assert(res == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback for do_rm_call_async_on_thread.
|
|
|
|
* Gets the command to invoke as the first argument to the command and runs it,
|
|
|
|
* passing the rest of the arguments to the command invocation.
|
|
|
|
* If the command got blocked, blocks the client and unblock on a background thread.
|
|
|
|
* this allows check the K (allow blocking) argument to RM_Call, and make sure that the reply
|
|
|
|
* that passes to unblock handler is owned by the handler and are not attached to any
|
|
|
|
* context that might be freed after the callback ends.
|
|
|
|
*/
|
|
|
|
int do_rm_call_async_on_thread(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);
|
|
|
|
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, cmd, "KEv", argv + 2, argc - 2);
|
|
|
|
|
|
|
|
if(RedisModule_CallReplyType(rep) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
rm_call_async_send_reply(ctx, rep);
|
|
|
|
} else {
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
RedisModule_CallReplyPromiseSetUnblockHandler(rep, rm_call_async_reply_on_thread, bc);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
Support for RM_Call on blocking commands (#11568)
Allow running blocking commands from within a module using `RM_Call`.
Today, when `RM_Call` is used, the fake client that is used to run command
is marked with `CLIENT_DENY_BLOCKING` flag. This flag tells the command
that it is not allowed to block the client and in case it needs to block, it must
fallback to some alternative (either return error or perform some default behavior).
For example, `BLPOP` fallback to simple `LPOP` if it is not allowed to block.
All the commands must respect the `CLIENT_DENY_BLOCKING` flag (including
module commands). When the command invocation finished, Redis asserts that
the client was not blocked.
This PR introduces the ability to call blocking command using `RM_Call` by
passing a callback that will be called when the client will get unblocked.
In order to do that, the user must explicitly say that he allow to perform blocking
command by passing a new format specifier argument, `K`, to the `RM_Call`
function. This new flag will tell Redis that it is allow to run blocking command
and block the client. In case the command got blocked, Redis will return a new
type of call reply (`REDISMODULE_REPLY_PROMISE`). This call reply indicates
that the command got blocked and the user can set the on_unblocked handler using
`RM_CallReplyPromiseSetUnblockHandler`.
When clients gets unblocked, it eventually reaches `processUnblockedClients` function.
This is where we check if the client is a fake module client and if it is, we call the unblock
callback instead of performing the usual unblock operations.
**Notice**: `RM_CallReplyPromiseSetUnblockHandler` must be called atomically
along side the command invocation (without releasing the Redis lock in between).
In addition, unlike other CallReply types, the promise call reply must be released
by the module when the Redis GIL is acquired.
The module can abort the execution on the blocking command (if it was not yet
executed) using `RM_CallReplyPromiseAbort`. the API will return `REDISMODULE_OK`
on success and `REDISMODULE_ERR` if the operation is already executed.
**Notice** that in case of misbehave module, Abort might finished successfully but the
operation will not really be aborted. This can only happened if the module do not respect
the disconnect callback of the blocked client.
For pure Redis commands this can not happened.
### Atomicity Guarantees
The API promise that the unblock handler will run atomically as an execution unit.
This means that all the operation performed on the unblock handler will be wrapped
with a multi exec transaction when replicated to the replica and AOF.
The API **do not** grantee any other atomicity properties such as when the unblock
handler will be called. This gives us the flexibility to strengthen the grantees (or not)
in the future if we will decide that we need a better guarantees.
That said, the implementation **does** provide a better guarantees when performing
pure Redis blocking command like `BLPOP`. In this case the unblock handler will run
atomically with the operation that got unblocked (for example, in case of `BLPOP`, the
unblock handler will run atomically with the `LPOP` operation that run when the command
got unblocked). This is an implementation detail that might be change in the future and the
module writer should not count on that.
### Calling blocking commands while running on script mode (`S`)
`RM_Call` script mode (`S`) was introduced on #0372. It is used for usecases where the
command that was invoked on `RM_Call` comes from a user input and we want to make
sure the user will not run dangerous commands like `shutdown`. Some command, such
as `BLPOP`, are marked with `NO_SCRIPT` flag, which means they will not be allowed on
script mode. Those commands are marked with `NO_SCRIPT` just because they are
blocking commands and not because they are dangerous. Now that we can run blocking
commands on RM_Call, there is no real reason not to allow such commands on script mode.
The underline problem is that the `NO_SCRIPT` flag is abused to also mark some of the
blocking commands (notice that those commands know not to block the client if it is not
allowed to do so, and have a fallback logic to such cases. So even if those commands
were not marked with `NO_SCRIPT` flag, it would not harm Redis, and today we can
already run those commands within multi exec).
In addition, not all blocking commands are marked with `NO_SCRIPT` flag, for example
`blmpop` are not marked and can run from within a script.
Those facts shows that there are some ambiguity about the meaning of the `NO_SCRIPT`
flag, and its not fully clear where it should be use.
The PR suggest that blocking commands should not be marked with `NO_SCRIPT` flag,
those commands should handle `CLIENT_DENY_BLOCKING` flag and only block when
it's safe (like they already does today). To achieve that, the PR removes the `NO_SCRIPT`
flag from the following commands:
* `blmove`
* `blpop`
* `brpop`
* `brpoplpush`
* `bzpopmax`
* `bzpopmin`
* `wait`
This might be considered a breaking change as now, on scripts, instead of getting
`command is not allowed from script` error, the user will get some fallback behavior
base on the command implementation. That said, the change matches the behavior
of scripts and multi exec with respect to those commands and allow running them on
`RM_Call` even when script mode is used.
### Additional RedisModule API and changes
* `RM_BlockClientSetPrivateData` - Set private data on the blocked client without the
need to unblock the client. This allows up to set the promise CallReply as the private
data of the blocked client and abort it if the client gets disconnected.
* `RM_BlockClientGetPrivateData` - Return the current private data set on a blocked client.
We need it so we will have access to this private data on the disconnect callback.
* On RM_Call, the returned reply will be added to the auto memory context only if auto
memory is enabled, this allows us to keep the call reply for longer time then the context
lifetime and does not force an unneeded borrow relationship between the CallReply and
the RedisModuleContext.
2023-03-16 08:04:31 -04:00
|
|
|
/* Private data for wait_and_do_rm_call_async that holds information about:
|
|
|
|
* 1. the block client, to unblock when done.
|
|
|
|
* 2. the arguments, contains the command to run using RM_Call */
|
|
|
|
typedef struct WaitAndDoRMCallCtx {
|
|
|
|
RedisModuleBlockedClient *bc;
|
|
|
|
RedisModuleString **argv;
|
|
|
|
int argc;
|
|
|
|
} WaitAndDoRMCallCtx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This callback will be called when the 'wait' command invoke on 'wait_and_do_rm_call_async' will finish.
|
|
|
|
* This callback will continue the execution flow just like 'do_rm_call_async' command.
|
|
|
|
*/
|
|
|
|
static void wait_and_do_rm_call_async_on_unblocked(RedisModuleCtx *ctx, RedisModuleCallReply *reply, void *private_data) {
|
|
|
|
WaitAndDoRMCallCtx *wctx = private_data;
|
|
|
|
if (RedisModule_CallReplyType(reply) != REDISMODULE_REPLY_INTEGER) {
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (RedisModule_CallReplyInteger(reply) != 1) {
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
RedisModule_FreeCallReply(reply);
|
|
|
|
reply = NULL;
|
|
|
|
|
|
|
|
const char* cmd = RedisModule_StringPtrLen(wctx->argv[0], NULL);
|
|
|
|
reply = RedisModule_Call(ctx, cmd, "!EKv", wctx->argv + 1, wctx->argc - 1);
|
|
|
|
|
|
|
|
done:
|
|
|
|
if(RedisModule_CallReplyType(reply) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
RedisModuleCtx *bctx = RedisModule_GetThreadSafeContext(wctx->bc);
|
|
|
|
rm_call_async_send_reply(bctx, reply);
|
|
|
|
RedisModule_FreeThreadSafeContext(bctx);
|
|
|
|
RedisModule_UnblockClient(wctx->bc, NULL);
|
|
|
|
} else {
|
|
|
|
RedisModule_CallReplyPromiseSetUnblockHandler(reply, rm_call_async_on_unblocked, wctx->bc);
|
|
|
|
RedisModule_FreeCallReply(reply);
|
|
|
|
}
|
|
|
|
for (int i = 0 ; i < wctx->argc ; ++i) {
|
|
|
|
RedisModule_FreeString(NULL, wctx->argv[i]);
|
|
|
|
}
|
|
|
|
RedisModule_Free(wctx->argv);
|
|
|
|
RedisModule_Free(wctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Callback for wait_and_do_rm_call
|
|
|
|
* Gets the command to invoke as the first argument, runs 'wait'
|
|
|
|
* command (using the K flag to RM_Call). Once the wait finished, runs the
|
|
|
|
* command that was given (just like 'do_rm_call_async').
|
|
|
|
*/
|
|
|
|
int wait_and_do_rm_call_async(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
if(argc < 2){
|
|
|
|
return RedisModule_WrongArity(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
int flags = RedisModule_GetContextFlags(ctx);
|
|
|
|
if (flags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING) {
|
|
|
|
return RedisModule_ReplyWithError(ctx, "Err can not run wait, blocking is not allowed.");
|
|
|
|
}
|
|
|
|
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, "wait", "!EKcc", "1", "0");
|
|
|
|
if(RedisModule_CallReplyType(rep) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
rm_call_async_send_reply(ctx, rep);
|
|
|
|
} else {
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
WaitAndDoRMCallCtx *wctx = RedisModule_Alloc(sizeof(*wctx));
|
|
|
|
*wctx = (WaitAndDoRMCallCtx){
|
|
|
|
.bc = bc,
|
|
|
|
.argv = RedisModule_Alloc((argc - 1) * sizeof(RedisModuleString*)),
|
|
|
|
.argc = argc - 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
for (int i = 1 ; i < argc ; ++i) {
|
|
|
|
wctx->argv[i - 1] = RedisModule_HoldString(NULL, argv[i]);
|
|
|
|
}
|
|
|
|
RedisModule_CallReplyPromiseSetUnblockHandler(rep, wait_and_do_rm_call_async_on_unblocked, wctx);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void blpop_and_set_multiple_keys_on_unblocked(RedisModuleCtx *ctx, RedisModuleCallReply *reply, void *private_data) {
|
|
|
|
/* ignore the reply */
|
|
|
|
RedisModule_FreeCallReply(reply);
|
|
|
|
WaitAndDoRMCallCtx *wctx = private_data;
|
|
|
|
for (int i = 0 ; i < wctx->argc ; i += 2) {
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, "set", "!ss", wctx->argv[i], wctx->argv[i + 1]);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
RedisModuleCtx *bctx = RedisModule_GetThreadSafeContext(wctx->bc);
|
|
|
|
RedisModule_ReplyWithSimpleString(bctx, "OK");
|
|
|
|
RedisModule_FreeThreadSafeContext(bctx);
|
|
|
|
RedisModule_UnblockClient(wctx->bc, NULL);
|
|
|
|
|
|
|
|
for (int i = 0 ; i < wctx->argc ; ++i) {
|
|
|
|
RedisModule_FreeString(NULL, wctx->argv[i]);
|
|
|
|
}
|
|
|
|
RedisModule_Free(wctx->argv);
|
|
|
|
RedisModule_Free(wctx);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Performs a blpop command on a given list and when unblocked set multiple string keys.
|
|
|
|
* This command allows checking that the unblock callback is performed as a unit
|
|
|
|
* and its effect are replicated to the replica and AOF wrapped with multi exec.
|
|
|
|
*/
|
|
|
|
int blpop_and_set_multiple_keys(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
|
|
|
|
UNUSED(argv);
|
|
|
|
UNUSED(argc);
|
|
|
|
|
|
|
|
if(argc < 2 || argc % 2 != 0){
|
|
|
|
return RedisModule_WrongArity(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
int flags = RedisModule_GetContextFlags(ctx);
|
|
|
|
if (flags & REDISMODULE_CTX_FLAGS_DENY_BLOCKING) {
|
|
|
|
return RedisModule_ReplyWithError(ctx, "Err can not run wait, blocking is not allowed.");
|
|
|
|
}
|
|
|
|
|
|
|
|
RedisModuleCallReply* rep = RedisModule_Call(ctx, "blpop", "!EKsc", argv[1], "0");
|
|
|
|
if(RedisModule_CallReplyType(rep) != REDISMODULE_REPLY_PROMISE) {
|
|
|
|
rm_call_async_send_reply(ctx, rep);
|
|
|
|
} else {
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
WaitAndDoRMCallCtx *wctx = RedisModule_Alloc(sizeof(*wctx));
|
|
|
|
*wctx = (WaitAndDoRMCallCtx){
|
|
|
|
.bc = bc,
|
|
|
|
.argv = RedisModule_Alloc((argc - 2) * sizeof(RedisModuleString*)),
|
|
|
|
.argc = argc - 2,
|
|
|
|
};
|
|
|
|
|
|
|
|
for (int i = 0 ; i < argc - 2 ; ++i) {
|
|
|
|
wctx->argv[i] = RedisModule_HoldString(NULL, argv[i + 2]);
|
|
|
|
}
|
|
|
|
RedisModule_CallReplyPromiseSetUnblockHandler(rep, blpop_and_set_multiple_keys_on_unblocked, wctx);
|
|
|
|
RedisModule_FreeCallReply(rep);
|
|
|
|
}
|
|
|
|
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2021-10-21 07:01:10 -04: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 11:58:55 -05:00
|
|
|
|
2022-01-20 02:05:53 -05: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;
|
|
|
|
}
|
|
|
|
|
Modules: Unblock from within a timer coverage (#12337)
Apart from adding the missing coverage, this PR also adds `blockedBeforeSleep`
that gathers all block-related functions from `beforeSleep`
The order inside `blockedBeforeSleep` is different: now `handleClientsBlockedOnKeys`
(which may unblock clients) is called before `processUnblockedClients` (which handles
unblocked clients).
It makes sense to have this order.
There are no visible effects of the wrong ordering, except some cleanups of the now-unblocked
client would have happen in the next `beforeSleep` (will now happen in the current one)
The reason we even got into it is because i triggers an assertion in logresreq.c (breaking
the assumption that `unblockClient` is called **before** actually flushing the reply to the socket):
`handleClientsBlockedOnKeys` is called, then it calls `moduleUnblockClientOnKey`, which calls
`moduleUnblockClient`, which adds the client to `moduleUnblockedClients` back to `beforeSleep`,
we call `handleClientsWithPendingWritesUsingThreads`, it writes the data of buf to the client, so
`client->bufpos` became 0
On the next `beforeSleep`, we call `moduleHandleBlockedClients`, which calls `unblockClient`,
which calls `reqresAppendResponse`, triggering the assert. (because the `bufpos` is 0) - see https://github.com/redis/redis/pull/12301#discussion_r1226386716
2023-06-22 16:15:16 -04:00
|
|
|
static void timer_callback(RedisModuleCtx *ctx, void *data)
|
|
|
|
{
|
|
|
|
UNUSED(ctx);
|
|
|
|
|
|
|
|
RedisModuleBlockedClient *bc = data;
|
|
|
|
|
|
|
|
// Get Redis module context
|
|
|
|
RedisModuleCtx *reply_ctx = RedisModule_GetThreadSafeContext(bc);
|
|
|
|
|
|
|
|
// Reply to client
|
|
|
|
RedisModule_ReplyWithSimpleString(reply_ctx, "OK");
|
|
|
|
|
|
|
|
// Unblock client
|
|
|
|
RedisModule_UnblockClient(bc, NULL);
|
|
|
|
|
|
|
|
// Free the Redis module context
|
|
|
|
RedisModule_FreeThreadSafeContext(reply_ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
int unblock_by_timer(RedisModuleCtx *ctx, RedisModuleString **argv, int argc)
|
|
|
|
{
|
|
|
|
if (argc != 2)
|
|
|
|
return RedisModule_WrongArity(ctx);
|
|
|
|
|
|
|
|
long long period;
|
|
|
|
if (RedisModule_StringToLongLong(argv[1],&period) != REDISMODULE_OK)
|
|
|
|
return RedisModule_ReplyWithError(ctx,"ERR invalid period");
|
|
|
|
|
|
|
|
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx, NULL, NULL, NULL, 0);
|
|
|
|
RedisModule_CreateTimer(ctx, period, timer_callback, bc);
|
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|
|
|
|
|
2020-09-09 09:01:16 -04: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 04:26:28 -05: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 11:58:55 -05:00
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
Support for RM_Call on blocking commands (#11568)
Allow running blocking commands from within a module using `RM_Call`.
Today, when `RM_Call` is used, the fake client that is used to run command
is marked with `CLIENT_DENY_BLOCKING` flag. This flag tells the command
that it is not allowed to block the client and in case it needs to block, it must
fallback to some alternative (either return error or perform some default behavior).
For example, `BLPOP` fallback to simple `LPOP` if it is not allowed to block.
All the commands must respect the `CLIENT_DENY_BLOCKING` flag (including
module commands). When the command invocation finished, Redis asserts that
the client was not blocked.
This PR introduces the ability to call blocking command using `RM_Call` by
passing a callback that will be called when the client will get unblocked.
In order to do that, the user must explicitly say that he allow to perform blocking
command by passing a new format specifier argument, `K`, to the `RM_Call`
function. This new flag will tell Redis that it is allow to run blocking command
and block the client. In case the command got blocked, Redis will return a new
type of call reply (`REDISMODULE_REPLY_PROMISE`). This call reply indicates
that the command got blocked and the user can set the on_unblocked handler using
`RM_CallReplyPromiseSetUnblockHandler`.
When clients gets unblocked, it eventually reaches `processUnblockedClients` function.
This is where we check if the client is a fake module client and if it is, we call the unblock
callback instead of performing the usual unblock operations.
**Notice**: `RM_CallReplyPromiseSetUnblockHandler` must be called atomically
along side the command invocation (without releasing the Redis lock in between).
In addition, unlike other CallReply types, the promise call reply must be released
by the module when the Redis GIL is acquired.
The module can abort the execution on the blocking command (if it was not yet
executed) using `RM_CallReplyPromiseAbort`. the API will return `REDISMODULE_OK`
on success and `REDISMODULE_ERR` if the operation is already executed.
**Notice** that in case of misbehave module, Abort might finished successfully but the
operation will not really be aborted. This can only happened if the module do not respect
the disconnect callback of the blocked client.
For pure Redis commands this can not happened.
### Atomicity Guarantees
The API promise that the unblock handler will run atomically as an execution unit.
This means that all the operation performed on the unblock handler will be wrapped
with a multi exec transaction when replicated to the replica and AOF.
The API **do not** grantee any other atomicity properties such as when the unblock
handler will be called. This gives us the flexibility to strengthen the grantees (or not)
in the future if we will decide that we need a better guarantees.
That said, the implementation **does** provide a better guarantees when performing
pure Redis blocking command like `BLPOP`. In this case the unblock handler will run
atomically with the operation that got unblocked (for example, in case of `BLPOP`, the
unblock handler will run atomically with the `LPOP` operation that run when the command
got unblocked). This is an implementation detail that might be change in the future and the
module writer should not count on that.
### Calling blocking commands while running on script mode (`S`)
`RM_Call` script mode (`S`) was introduced on #0372. It is used for usecases where the
command that was invoked on `RM_Call` comes from a user input and we want to make
sure the user will not run dangerous commands like `shutdown`. Some command, such
as `BLPOP`, are marked with `NO_SCRIPT` flag, which means they will not be allowed on
script mode. Those commands are marked with `NO_SCRIPT` just because they are
blocking commands and not because they are dangerous. Now that we can run blocking
commands on RM_Call, there is no real reason not to allow such commands on script mode.
The underline problem is that the `NO_SCRIPT` flag is abused to also mark some of the
blocking commands (notice that those commands know not to block the client if it is not
allowed to do so, and have a fallback logic to such cases. So even if those commands
were not marked with `NO_SCRIPT` flag, it would not harm Redis, and today we can
already run those commands within multi exec).
In addition, not all blocking commands are marked with `NO_SCRIPT` flag, for example
`blmpop` are not marked and can run from within a script.
Those facts shows that there are some ambiguity about the meaning of the `NO_SCRIPT`
flag, and its not fully clear where it should be use.
The PR suggest that blocking commands should not be marked with `NO_SCRIPT` flag,
those commands should handle `CLIENT_DENY_BLOCKING` flag and only block when
it's safe (like they already does today). To achieve that, the PR removes the `NO_SCRIPT`
flag from the following commands:
* `blmove`
* `blpop`
* `brpop`
* `brpoplpush`
* `bzpopmax`
* `bzpopmin`
* `wait`
This might be considered a breaking change as now, on scripts, instead of getting
`command is not allowed from script` error, the user will get some fallback behavior
base on the command implementation. That said, the change matches the behavior
of scripts and multi exec with respect to those commands and allow running them on
`RM_Call` even when script mode is used.
### Additional RedisModule API and changes
* `RM_BlockClientSetPrivateData` - Set private data on the blocked client without the
need to unblock the client. This allows up to set the promise CallReply as the private
data of the blocked client and abort it if the client gets disconnected.
* `RM_BlockClientGetPrivateData` - Return the current private data set on a blocked client.
We need it so we will have access to this private data on the disconnect callback.
* On RM_Call, the returned reply will be added to the auto memory context only if auto
memory is enabled, this allows us to keep the call reply for longer time then the context
lifetime and does not force an unneeded borrow relationship between the CallReply and
the RedisModuleContext.
2023-03-16 08:04:31 -04:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call_async", do_rm_call_async,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2023-06-25 07:12:27 -04:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call_async_on_thread", do_rm_call_async_on_thread,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
Support for RM_Call on blocking commands (#11568)
Allow running blocking commands from within a module using `RM_Call`.
Today, when `RM_Call` is used, the fake client that is used to run command
is marked with `CLIENT_DENY_BLOCKING` flag. This flag tells the command
that it is not allowed to block the client and in case it needs to block, it must
fallback to some alternative (either return error or perform some default behavior).
For example, `BLPOP` fallback to simple `LPOP` if it is not allowed to block.
All the commands must respect the `CLIENT_DENY_BLOCKING` flag (including
module commands). When the command invocation finished, Redis asserts that
the client was not blocked.
This PR introduces the ability to call blocking command using `RM_Call` by
passing a callback that will be called when the client will get unblocked.
In order to do that, the user must explicitly say that he allow to perform blocking
command by passing a new format specifier argument, `K`, to the `RM_Call`
function. This new flag will tell Redis that it is allow to run blocking command
and block the client. In case the command got blocked, Redis will return a new
type of call reply (`REDISMODULE_REPLY_PROMISE`). This call reply indicates
that the command got blocked and the user can set the on_unblocked handler using
`RM_CallReplyPromiseSetUnblockHandler`.
When clients gets unblocked, it eventually reaches `processUnblockedClients` function.
This is where we check if the client is a fake module client and if it is, we call the unblock
callback instead of performing the usual unblock operations.
**Notice**: `RM_CallReplyPromiseSetUnblockHandler` must be called atomically
along side the command invocation (without releasing the Redis lock in between).
In addition, unlike other CallReply types, the promise call reply must be released
by the module when the Redis GIL is acquired.
The module can abort the execution on the blocking command (if it was not yet
executed) using `RM_CallReplyPromiseAbort`. the API will return `REDISMODULE_OK`
on success and `REDISMODULE_ERR` if the operation is already executed.
**Notice** that in case of misbehave module, Abort might finished successfully but the
operation will not really be aborted. This can only happened if the module do not respect
the disconnect callback of the blocked client.
For pure Redis commands this can not happened.
### Atomicity Guarantees
The API promise that the unblock handler will run atomically as an execution unit.
This means that all the operation performed on the unblock handler will be wrapped
with a multi exec transaction when replicated to the replica and AOF.
The API **do not** grantee any other atomicity properties such as when the unblock
handler will be called. This gives us the flexibility to strengthen the grantees (or not)
in the future if we will decide that we need a better guarantees.
That said, the implementation **does** provide a better guarantees when performing
pure Redis blocking command like `BLPOP`. In this case the unblock handler will run
atomically with the operation that got unblocked (for example, in case of `BLPOP`, the
unblock handler will run atomically with the `LPOP` operation that run when the command
got unblocked). This is an implementation detail that might be change in the future and the
module writer should not count on that.
### Calling blocking commands while running on script mode (`S`)
`RM_Call` script mode (`S`) was introduced on #0372. It is used for usecases where the
command that was invoked on `RM_Call` comes from a user input and we want to make
sure the user will not run dangerous commands like `shutdown`. Some command, such
as `BLPOP`, are marked with `NO_SCRIPT` flag, which means they will not be allowed on
script mode. Those commands are marked with `NO_SCRIPT` just because they are
blocking commands and not because they are dangerous. Now that we can run blocking
commands on RM_Call, there is no real reason not to allow such commands on script mode.
The underline problem is that the `NO_SCRIPT` flag is abused to also mark some of the
blocking commands (notice that those commands know not to block the client if it is not
allowed to do so, and have a fallback logic to such cases. So even if those commands
were not marked with `NO_SCRIPT` flag, it would not harm Redis, and today we can
already run those commands within multi exec).
In addition, not all blocking commands are marked with `NO_SCRIPT` flag, for example
`blmpop` are not marked and can run from within a script.
Those facts shows that there are some ambiguity about the meaning of the `NO_SCRIPT`
flag, and its not fully clear where it should be use.
The PR suggest that blocking commands should not be marked with `NO_SCRIPT` flag,
those commands should handle `CLIENT_DENY_BLOCKING` flag and only block when
it's safe (like they already does today). To achieve that, the PR removes the `NO_SCRIPT`
flag from the following commands:
* `blmove`
* `blpop`
* `brpop`
* `brpoplpush`
* `bzpopmax`
* `bzpopmin`
* `wait`
This might be considered a breaking change as now, on scripts, instead of getting
`command is not allowed from script` error, the user will get some fallback behavior
base on the command implementation. That said, the change matches the behavior
of scripts and multi exec with respect to those commands and allow running them on
`RM_Call` even when script mode is used.
### Additional RedisModule API and changes
* `RM_BlockClientSetPrivateData` - Set private data on the blocked client without the
need to unblock the client. This allows up to set the promise CallReply as the private
data of the blocked client and abort it if the client gets disconnected.
* `RM_BlockClientGetPrivateData` - Return the current private data set on a blocked client.
We need it so we will have access to this private data on the disconnect callback.
* On RM_Call, the returned reply will be added to the auto memory context only if auto
memory is enabled, this allows us to keep the call reply for longer time then the context
lifetime and does not force an unneeded borrow relationship between the CallReply and
the RedisModuleContext.
2023-03-16 08:04:31 -04:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call_async_script_mode", do_rm_call_async,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call_async_no_replicate", do_rm_call_async,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "do_rm_call_fire_and_forget", do_rm_call_async_fire_and_forget,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "wait_and_do_rm_call", wait_and_do_rm_call_async,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
|
|
|
if (RedisModule_CreateCommand(ctx, "blpop_and_set_multiple_keys", blpop_and_set_multiple_keys,
|
|
|
|
"write", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2020-12-08 09:41:20 -05:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_bg_rm_call", do_bg_rm_call, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2022-06-21 03:01:13 -04: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 07:01:10 -04:00
|
|
|
if (RedisModule_CreateCommand(ctx, "do_fake_bg_true", do_fake_bg_true, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2022-01-20 02:05:53 -05: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;
|
|
|
|
|
Modules: Unblock from within a timer coverage (#12337)
Apart from adding the missing coverage, this PR also adds `blockedBeforeSleep`
that gathers all block-related functions from `beforeSleep`
The order inside `blockedBeforeSleep` is different: now `handleClientsBlockedOnKeys`
(which may unblock clients) is called before `processUnblockedClients` (which handles
unblocked clients).
It makes sense to have this order.
There are no visible effects of the wrong ordering, except some cleanups of the now-unblocked
client would have happen in the next `beforeSleep` (will now happen in the current one)
The reason we even got into it is because i triggers an assertion in logresreq.c (breaking
the assumption that `unblockClient` is called **before** actually flushing the reply to the socket):
`handleClientsBlockedOnKeys` is called, then it calls `moduleUnblockClientOnKey`, which calls
`moduleUnblockClient`, which adds the client to `moduleUnblockedClients` back to `beforeSleep`,
we call `handleClientsWithPendingWritesUsingThreads`, it writes the data of buf to the client, so
`client->bufpos` became 0
On the next `beforeSleep`, we call `moduleHandleBlockedClients`, which calls `unblockClient`,
which calls `reqresAppendResponse`, triggering the assert. (because the `bufpos` is 0) - see https://github.com/redis/redis/pull/12301#discussion_r1226386716
2023-06-22 16:15:16 -04:00
|
|
|
if (RedisModule_CreateCommand(ctx, "unblock_by_timer", unblock_by_timer, "", 0, 0, 0) == REDISMODULE_ERR)
|
|
|
|
return REDISMODULE_ERR;
|
|
|
|
|
2020-09-09 09:01:16 -04:00
|
|
|
return REDISMODULE_OK;
|
|
|
|
}
|