Adding module api for processing commands during busy jobs and allow flagging the commands that should be handled at this status #9963

perryitay · 2021-12-19T09:51:57Z

issue : #9655

Some modules might perform a long-running logic in different stages of Redis lifetime, for example:

command execution
RDB loading
thread safe context

During this long-running logic Redis is not responsive.

This PR offers

An API to process events while a busy command is running (RM_Yield)
A new flag (ALLOW_BUSY) to mark the commands that should be handled during busy
jobs which can also be used by modules (allow-busy)
In slow commands and thread safe contexts, this flag will start rejecting commands with -BUSY only
after busy-reply-threshold
During loading (rdb_load callback), it'll process events right away (not wait for busy-reply-threshold),
but either way, the processing is throttled to the server hz rate.
Allow modules to Yield to redis background tasks, but not to client commands

rename script-time-limit to busy-reply-threshold (an alias to the pre-7.0 lua-time-limit)

src/module.c

src/server.c

src/server.h

tests/modules/list.c

tests/unit/moduleapi/list.tcl

MeirShpilraien · 2021-12-22T19:00:07Z

Suggestion, why not using the script timeout mechanism here:

redis/src/script.c

Line 71 in e33e029

int scriptInterrupt(scriptRunCtx *run_ctx) {

?
We can create scriptRunCtx and set it on RedisModuleCtx, then we will be able to call this API and share the code, WDYT?

In addition, I believe we should consider whether or not this can be called from a thread safe context (I believe that we should support it, many of our modules needs to call if from a thread). And we should probably add tests that uses it from a thread safe context if we decide that its supported.

oranagra · 2021-12-22T20:15:00Z

@MeirShpilraien if feels to me like trying to tie two things that are not really related, and i suspect it'll cause complications in the future.
maybe i'm missing something, but if it's just about replicating 10 lines of code that don't contain any very sensitive code, we better go with the cloning approach.

guybe7 · 2021-12-22T21:43:18Z

maybe i'm missing something but if we have a module command that does something heavy, shouldn't it just block the client and do the heavy lifting in a thread?
or maybe we're talking about a case where you deliberately want to prevent the server from executing most of the commands while your module command is doing something? is there a concrete example for such a case?

MeirShpilraien · 2021-12-23T06:55:43Z

@MeirShpilraien if feels to me like trying to tie two things that are not really related, and i suspect it'll cause complications in the future.
maybe i'm missing something, but if it's just about replicating 10 lines of code that don't contain any very sensitive code, we better go with the cloning approach.

@oranagra I can see how it can be useful on more places, for example RM_Call and scriptCall has a huge code duplication of basically invoking commands on Redis.

I agree though that it will probably require more effort to match this code to what we need so we can leave it for the future I guess.

maybe i'm missing something but if we have a module command that does something heavy, shouldn't it just block the client and do the heavy lifting in a thread?

@guybe7 the use-case is that when a module need to do a long operation which need to be atomic and then it needs to lock the GIL for a long time.

…context

itamarhaber

!CR

redis.conf

oranagra · 2022-01-18T22:13:28Z

@madolson i'd appreciate a review of my last commit.
maybe we should rename BLOCKED_PAUSE to BLOCKED_POSTPONED since i think it just means that processCommand tried to process it and decided to postpone it.
or, if you find bugs in my code, maybe i need to create a dedicated BLOCKED_YIELD flag.

madolson

I don't think we need a new BLOCKED_YIELD, this should work as expected.

src/server.c

src/networking.c

src/module.c

src/server.c

Co-authored-by: Yossi Gottlieb <yossigo@gmail.com>

src/module.c

Co-authored-by: sundb <sundbcn@gmail.com>

sundb · 2022-01-20T06:01:44Z

It seems that replconfCommand and quitCommand missing CMD_ALLOW_BUSY.

    if (scriptIsTimedout() &&
          c->cmd->proc != authCommand &&
          c->cmd->proc != helloCommand &&
          c->cmd->proc != replconfCommand &&        <- missing
          c->cmd->proc != multiCommand &&
          c->cmd->proc != discardCommand &&
          c->cmd->proc != watchCommand &&
          c->cmd->proc != unwatchCommand &&
          c->cmd->proc != quitCommand &&            <- missing
          c->cmd->proc != resetCommand &&
          c->cmd->proc != shutdownCommand && /* more checks in shutdownCommand */
        !(c->cmd->proc == scriptCommand &&

oranagra · 2022-01-20T06:52:47Z

It seems that replconfCommand and quitCommand missing CMD_ALLOW_BUSY.

good catch.. i guess it was a bad merge conflict resolution.

## Issues and solutions from #12817 1. Touch ProcessingEventsWhileBlocked and calling moduleCount() without GIL in afterSleep() - Introduced: Version: 7.0.0 PR: #9963 - Harm Level: Very High If the module thread calls `RM_Yield()` before the main thread enters afterSleep(), and modifies `ProcessingEventsWhileBlocked`(+1), it will cause the main thread to not wait for GIL, which can lead to all kinds of unforeseen problems, including memory data corruption. - Initial / Abandoned Solution: * Added `__thread` specifier for ProcessingEventsWhileBlocked. `ProcessingEventsWhileBlocked` is used to protect against nested event processing, but event processing in the main thread and module threads should be completely independent and unaffected, so it is safer to use TLS. * Adding a cached module count to keep track of the current number of modules, to avoid having to use `dictSize()`. - Related Warnings: ``` WARNING: ThreadSanitizer: data race (pid=1136) Write of size 4 at 0x0001045990c0 by thread T4 (mutexes: write M0): #0 processEventsWhileBlocked networking.c:4135 (redis-server:arm64+0x10006d124) #1 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) #2 bg_call_worker <null>:83232836 (blockedclient.so:arm64+0x16a8) Previous read of size 4 at 0x0001045990c0 by main thread: #0 afterSleep server.c:1861 (redis-server:arm64+0x100024f98) #1 aeProcessEvents ae.c:408 (redis-server:arm64+0x10000fd64) #2 aeMain ae.c:496 (redis-server:arm64+0x100010f0c) #3 main server.c:7220 (redis-server:arm64+0x10003f38c) ``` 2. aeApiPoll() is not thread-safe When using RM_Yield to handle events in a module thread, if the main thread has not yet entered `afterSleep()`, both the module thread and the main thread may touch `server.el` at the same time. - Introduced: Version: 7.0.0 PR: #9963 - Old / Abandoned Solution: Adding a new mutex to protect timing between after beforeSleep() and before afterSleep(). Defect: If the main thread enters the ae loop without any IO events, it will wait until the next timeout or until there is any event again, and the module thread will always hang until the main thread leaves the event loop. - Related Warnings: ``` SUMMARY: ThreadSanitizer: data race ae_kqueue.c:55 in addEventMask ================== ================== WARNING: ThreadSanitizer: data race (pid=14682) Write of size 4 at 0x000100b54000 by thread T9 (mutexes: write M0): #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) #1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) #2 processEventsWhileBlocked networking.c:4138 (redis-server:arm64+0x10006d3c4) #3 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) #4 bg_call_worker <null>:16042052 (blockedclient.so:arm64+0x169c) Previous write of size 4 at 0x000100b54000 by main thread: #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) #1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) #2 aeMain ae.c:496 (redis-server:arm64+0x100010da8) #3 main server.c:7238 (redis-server:arm64+0x10003f51c) ``` ## The final fix as the comments: #12817 (comment) Optimized solution based on the above comment: First, we add `module_gil_acquring` to indicate whether the main thread is currently in the acquiring GIL state. When the module thread starts to yield, there are two possibilities(we assume the caller keeps the GIL): 1. The main thread is in the mid of beforeSleep() and afterSleep(), that is, `module_gil_acquring` is not 1 now. At this point, the module thread will wake up the main thread through the pipe and leave the yield, waiting for the next yield when the main thread may already in the acquiring GIL state. 2. The main thread is in the acquiring GIL state. The module thread release the GIL, yielding CPU to give the main thread an opportunity to start event processing, and then acquire the GIL again until the main thread releases it. This is what #12817 (comment) mentioned direction. --------- Co-authored-by: Oran Agra <oran@redislabs.com>

## Issues and solutions from redis#12817 1. Touch ProcessingEventsWhileBlocked and calling moduleCount() without GIL in afterSleep() - Introduced: Version: 7.0.0 PR: redis#9963 - Harm Level: Very High If the module thread calls `RM_Yield()` before the main thread enters afterSleep(), and modifies `ProcessingEventsWhileBlocked`(+1), it will cause the main thread to not wait for GIL, which can lead to all kinds of unforeseen problems, including memory data corruption. - Initial / Abandoned Solution: * Added `__thread` specifier for ProcessingEventsWhileBlocked. `ProcessingEventsWhileBlocked` is used to protect against nested event processing, but event processing in the main thread and module threads should be completely independent and unaffected, so it is safer to use TLS. * Adding a cached module count to keep track of the current number of modules, to avoid having to use `dictSize()`. - Related Warnings: ``` WARNING: ThreadSanitizer: data race (pid=1136) Write of size 4 at 0x0001045990c0 by thread T4 (mutexes: write M0): #0 processEventsWhileBlocked networking.c:4135 (redis-server:arm64+0x10006d124) redis#1 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) redis#2 bg_call_worker <null>:83232836 (blockedclient.so:arm64+0x16a8) Previous read of size 4 at 0x0001045990c0 by main thread: #0 afterSleep server.c:1861 (redis-server:arm64+0x100024f98) redis#1 aeProcessEvents ae.c:408 (redis-server:arm64+0x10000fd64) redis#2 aeMain ae.c:496 (redis-server:arm64+0x100010f0c) redis#3 main server.c:7220 (redis-server:arm64+0x10003f38c) ``` 2. aeApiPoll() is not thread-safe When using RM_Yield to handle events in a module thread, if the main thread has not yet entered `afterSleep()`, both the module thread and the main thread may touch `server.el` at the same time. - Introduced: Version: 7.0.0 PR: redis#9963 - Old / Abandoned Solution: Adding a new mutex to protect timing between after beforeSleep() and before afterSleep(). Defect: If the main thread enters the ae loop without any IO events, it will wait until the next timeout or until there is any event again, and the module thread will always hang until the main thread leaves the event loop. - Related Warnings: ``` SUMMARY: ThreadSanitizer: data race ae_kqueue.c:55 in addEventMask ================== ================== WARNING: ThreadSanitizer: data race (pid=14682) Write of size 4 at 0x000100b54000 by thread T9 (mutexes: write M0): #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) redis#1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) redis#2 processEventsWhileBlocked networking.c:4138 (redis-server:arm64+0x10006d3c4) redis#3 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) redis#4 bg_call_worker <null>:16042052 (blockedclient.so:arm64+0x169c) Previous write of size 4 at 0x000100b54000 by main thread: #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) redis#1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) redis#2 aeMain ae.c:496 (redis-server:arm64+0x100010da8) redis#3 main server.c:7238 (redis-server:arm64+0x10003f51c) ``` ## The final fix as the comments: redis#12817 (comment) Optimized solution based on the above comment: First, we add `module_gil_acquring` to indicate whether the main thread is currently in the acquiring GIL state. When the module thread starts to yield, there are two possibilities(we assume the caller keeps the GIL): 1. The main thread is in the mid of beforeSleep() and afterSleep(), that is, `module_gil_acquring` is not 1 now. At this point, the module thread will wake up the main thread through the pipe and leave the yield, waiting for the next yield when the main thread may already in the acquiring GIL state. 2. The main thread is in the acquiring GIL state. The module thread release the GIL, yielding CPU to give the main thread an opportunity to start event processing, and then acquire the GIL again until the main thread releases it. This is what redis#12817 (comment) mentioned direction. --------- Co-authored-by: Oran Agra <oran@redislabs.com>

1. Touch ProcessingEventsWhileBlocked and calling moduleCount() without GIL in afterSleep() - Introduced: Version: 7.0.0 PR: redis#9963 - Harm Level: Very High If the module thread calls `RM_Yield()` before the main thread enters afterSleep(), and modifies `ProcessingEventsWhileBlocked`(+1), it will cause the main thread to not wait for GIL, which can lead to all kinds of unforeseen problems, including memory data corruption. - Initial / Abandoned Solution: * Added `__thread` specifier for ProcessingEventsWhileBlocked. `ProcessingEventsWhileBlocked` is used to protect against nested event processing, but event processing in the main thread and module threads should be completely independent and unaffected, so it is safer to use TLS. * Adding a cached module count to keep track of the current number of modules, to avoid having to use `dictSize()`. - Related Warnings: ``` WARNING: ThreadSanitizer: data race (pid=1136) Write of size 4 at 0x0001045990c0 by thread T4 (mutexes: write M0): Previous read of size 4 at 0x0001045990c0 by main thread: ``` 2. aeApiPoll() is not thread-safe When using RM_Yield to handle events in a module thread, if the main thread has not yet entered `afterSleep()`, both the module thread and the main thread may touch `server.el` at the same time. - Introduced: Version: 7.0.0 PR: redis#9963 - Old / Abandoned Solution: Adding a new mutex to protect timing between after beforeSleep() and before afterSleep(). Defect: If the main thread enters the ae loop without any IO events, it will wait until the next timeout or until there is any event again, and the module thread will always hang until the main thread leaves the event loop. - Related Warnings: ``` SUMMARY: ThreadSanitizer: data race ae_kqueue.c:55 in addEventMask ================== ================== WARNING: ThreadSanitizer: data race (pid=14682) Write of size 4 at 0x000100b54000 by thread T9 (mutexes: write M0): Previous write of size 4 at 0x000100b54000 by main thread: ``` redis#12817 (comment) Optimized solution based on the above comment: First, we add `module_gil_acquring` to indicate whether the main thread is currently in the acquiring GIL state. When the module thread starts to yield, there are two possibilities(we assume the caller keeps the GIL): 1. The main thread is in the mid of beforeSleep() and afterSleep(), that is, `module_gil_acquring` is not 1 now. At this point, the module thread will wake up the main thread through the pipe and leave the yield, waiting for the next yield when the main thread may already in the acquiring GIL state. 2. The main thread is in the acquiring GIL state. The module thread release the GIL, yielding CPU to give the main thread an opportunity to start event processing, and then acquire the GIL again until the main thread releases it. This is what redis#12817 (comment) mentioned direction. --------- Co-authored-by: Oran Agra <oran@redislabs.com>

## Issues and solutions from redis#12817 1. Touch ProcessingEventsWhileBlocked and calling moduleCount() without GIL in afterSleep() - Introduced: Version: 7.0.0 PR: redis#9963 - Harm Level: Very High If the module thread calls `RM_Yield()` before the main thread enters afterSleep(), and modifies `ProcessingEventsWhileBlocked`(+1), it will cause the main thread to not wait for GIL, which can lead to all kinds of unforeseen problems, including memory data corruption. - Initial / Abandoned Solution: * Added `__thread` specifier for ProcessingEventsWhileBlocked. `ProcessingEventsWhileBlocked` is used to protect against nested event processing, but event processing in the main thread and module threads should be completely independent and unaffected, so it is safer to use TLS. * Adding a cached module count to keep track of the current number of modules, to avoid having to use `dictSize()`. - Related Warnings: ``` WARNING: ThreadSanitizer: data race (pid=1136) Write of size 4 at 0x0001045990c0 by thread T4 (mutexes: write M0): #0 processEventsWhileBlocked networking.c:4135 (redis-server:arm64+0x10006d124) #1 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) #2 bg_call_worker <null>:83232836 (blockedclient.so:arm64+0x16a8) Previous read of size 4 at 0x0001045990c0 by main thread: #0 afterSleep server.c:1861 (redis-server:arm64+0x100024f98) #1 aeProcessEvents ae.c:408 (redis-server:arm64+0x10000fd64) #2 aeMain ae.c:496 (redis-server:arm64+0x100010f0c) #3 main server.c:7220 (redis-server:arm64+0x10003f38c) ``` 2. aeApiPoll() is not thread-safe When using RM_Yield to handle events in a module thread, if the main thread has not yet entered `afterSleep()`, both the module thread and the main thread may touch `server.el` at the same time. - Introduced: Version: 7.0.0 PR: redis#9963 - Old / Abandoned Solution: Adding a new mutex to protect timing between after beforeSleep() and before afterSleep(). Defect: If the main thread enters the ae loop without any IO events, it will wait until the next timeout or until there is any event again, and the module thread will always hang until the main thread leaves the event loop. - Related Warnings: ``` SUMMARY: ThreadSanitizer: data race ae_kqueue.c:55 in addEventMask ================== ================== WARNING: ThreadSanitizer: data race (pid=14682) Write of size 4 at 0x000100b54000 by thread T9 (mutexes: write M0): #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) #1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) #2 processEventsWhileBlocked networking.c:4138 (redis-server:arm64+0x10006d3c4) #3 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) #4 bg_call_worker <null>:16042052 (blockedclient.so:arm64+0x169c) Previous write of size 4 at 0x000100b54000 by main thread: #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) #1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) #2 aeMain ae.c:496 (redis-server:arm64+0x100010da8) #3 main server.c:7238 (redis-server:arm64+0x10003f51c) ``` ## The final fix as the comments: redis#12817 (comment) Optimized solution based on the above comment: First, we add `module_gil_acquring` to indicate whether the main thread is currently in the acquiring GIL state. When the module thread starts to yield, there are two possibilities(we assume the caller keeps the GIL): 1. The main thread is in the mid of beforeSleep() and afterSleep(), that is, `module_gil_acquring` is not 1 now. At this point, the module thread will wake up the main thread through the pipe and leave the yield, waiting for the next yield when the main thread may already in the acquiring GIL state. 2. The main thread is in the acquiring GIL state. The module thread release the GIL, yielding CPU to give the main thread an opportunity to start event processing, and then acquire the GIL again until the main thread releases it. This is what redis#12817 (comment) mentioned direction. --------- Co-authored-by: Oran Agra <oran@redislabs.com>

## Issues and solutions from redis#12817 1. Touch ProcessingEventsWhileBlocked and calling moduleCount() without GIL in afterSleep() - Introduced: Version: 7.0.0 PR: redis#9963 - Harm Level: Very High If the module thread calls `RM_Yield()` before the main thread enters afterSleep(), and modifies `ProcessingEventsWhileBlocked`(+1), it will cause the main thread to not wait for GIL, which can lead to all kinds of unforeseen problems, including memory data corruption. - Initial / Abandoned Solution: * Added `__thread` specifier for ProcessingEventsWhileBlocked. `ProcessingEventsWhileBlocked` is used to protect against nested event processing, but event processing in the main thread and module threads should be completely independent and unaffected, so it is safer to use TLS. * Adding a cached module count to keep track of the current number of modules, to avoid having to use `dictSize()`. - Related Warnings: ``` WARNING: ThreadSanitizer: data race (pid=1136) Write of size 4 at 0x0001045990c0 by thread T4 (mutexes: write M0): #0 processEventsWhileBlocked networking.c:4135 (redis-server:arm64+0x10006d124) redis#1 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) redis#2 bg_call_worker <null>:83232836 (blockedclient.so:arm64+0x16a8) Previous read of size 4 at 0x0001045990c0 by main thread: #0 afterSleep server.c:1861 (redis-server:arm64+0x100024f98) redis#1 aeProcessEvents ae.c:408 (redis-server:arm64+0x10000fd64) redis#2 aeMain ae.c:496 (redis-server:arm64+0x100010f0c) redis#3 main server.c:7220 (redis-server:arm64+0x10003f38c) ``` 2. aeApiPoll() is not thread-safe When using RM_Yield to handle events in a module thread, if the main thread has not yet entered `afterSleep()`, both the module thread and the main thread may touch `server.el` at the same time. - Introduced: Version: 7.0.0 PR: redis#9963 - Old / Abandoned Solution: Adding a new mutex to protect timing between after beforeSleep() and before afterSleep(). Defect: If the main thread enters the ae loop without any IO events, it will wait until the next timeout or until there is any event again, and the module thread will always hang until the main thread leaves the event loop. - Related Warnings: ``` SUMMARY: ThreadSanitizer: data race ae_kqueue.c:55 in addEventMask ================== ================== WARNING: ThreadSanitizer: data race (pid=14682) Write of size 4 at 0x000100b54000 by thread T9 (mutexes: write M0): #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) redis#1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) redis#2 processEventsWhileBlocked networking.c:4138 (redis-server:arm64+0x10006d3c4) redis#3 RM_Yield module.c:2410 (redis-server:arm64+0x10018b66c) redis#4 bg_call_worker <null>:16042052 (blockedclient.so:arm64+0x169c) Previous write of size 4 at 0x000100b54000 by main thread: #0 aeApiPoll ae_kqueue.c:175 (redis-server:arm64+0x100010588) redis#1 aeProcessEvents ae.c:399 (redis-server:arm64+0x10000fb84) redis#2 aeMain ae.c:496 (redis-server:arm64+0x100010da8) redis#3 main server.c:7238 (redis-server:arm64+0x10003f51c) ``` ## The final fix as the comments: redis#12817 (comment) Optimized solution based on the above comment: First, we add `module_gil_acquring` to indicate whether the main thread is currently in the acquiring GIL state. When the module thread starts to yield, there are two possibilities(we assume the caller keeps the GIL): 1. The main thread is in the mid of beforeSleep() and afterSleep(), that is, `module_gil_acquring` is not 1 now. At this point, the module thread will wake up the main thread through the pipe and leave the yield, waiting for the next yield when the main thread may already in the acquiring GIL state. 2. The main thread is in the acquiring GIL state. The module thread release the GIL, yielding CPU to give the main thread an opportunity to start event processing, and then acquire the GIL again until the main thread releases it. This is what redis#12817 (comment) mentioned direction. --------- Co-authored-by: Oran Agra <oran@redislabs.com>

perryitay added 3 commits December 15, 2021 05:24

adding handling jobs during busy jobs in module

33f5f99

Merge branch 'unstable' of github.com:redis/redis into unstable

f305260

fix issues that occured while git pulling

a1af268

perryitay changed the title ~~Busy commands module~~ Adding module api for processing commands during busy jobs and allow flagging the commands that should be handled at this status Dec 19, 2021

oranagra reviewed Dec 19, 2021

View reviewed changes

oranagra added 7.0-must-have and removed 7.0-must-have labels Dec 20, 2021

oranagra linked an issue Dec 22, 2021 that may be closed by this pull request

Module API to process commands while blocked. #9655

Closed

perryitay force-pushed the busy-commands-module branch from 6b4a379 to 318aa31 Compare December 23, 2021 08:43

Merge branch 'unstable' into busy-commands-module

dfc50e0

perryitay force-pushed the busy-commands-module branch 5 times, most recently from a566a73 to c2082ac Compare December 23, 2021 10:10

Merge branch 'unstable' into busy-commands-module

f3673ae

perryitay force-pushed the busy-commands-module branch from c2082ac to f3673ae Compare December 23, 2021 10:12

fixing the timing mechanism for busy commands

62c2cae

perryitay and others added 5 commits January 5, 2022 02:33

use blockingOperationEnds and blockingOperationStarts in the correct …

5b064b9

…context

Merge branch 'unstable' into busy-commands-module

dc8a093

cleanup

483397f

fixes

685b44a

move api to anther documentation section

8035bdf

itamarhaber approved these changes Jan 18, 2022

View reviewed changes

redis.conf Outdated Show resolved Hide resolved

implement support for RM_Yield with BUSY_MODULE_YIELD_EVENTS

090436f

wording and test failure

e6f3cb3

madolson reviewed Jan 19, 2022

View reviewed changes

src/server.c Show resolved Hide resolved

src/networking.c Show resolved Hide resolved

src/module.c Show resolved Hide resolved

src/server.c Show resolved Hide resolved

oranagra and others added 2 commits January 19, 2022 09:05

rename BLOCKED_PAUSED to BLOCKED_POSTPONED, add comments, fix CR

a62d329

typo in comment

2848cde

Co-authored-by: Yossi Gottlieb <yossigo@gmail.com>

yossigo approved these changes Jan 19, 2022

View reviewed changes

sundb reviewed Jan 20, 2022

View reviewed changes

src/module.c Outdated Show resolved Hide resolved

sundb reviewed Jan 20, 2022

View reviewed changes

src/module.c Outdated Show resolved Hide resolved

madolson approved these changes Jan 20, 2022

View reviewed changes

sundb reviewed Jan 20, 2022

View reviewed changes

src/module.c Show resolved Hide resolved

typos

e91571d

Co-authored-by: sundb <sundbcn@gmail.com>

add allow_busy to quit and replicaof

bccc7e7

oranagra merged commit c4b7882 into redis:unstable Jan 20, 2022

enjoy-binbin mentioned this pull request Feb 20, 2022

Remove ALLOW_BUSY from REPLICAOF and add it to REPLCONF. Add DEPRECATED doc flag to SLAVEOF, mark it as deprecated. #10315

Merged

soloestoy mentioned this pull request Apr 6, 2022

Durability enhancement for appendfsync=always policy #9678

Merged

MeirShpilraien mentioned this pull request Dec 5, 2022

Cleanup: Get rid of server.core_propagates #11572

Merged

sundb mentioned this pull request Nov 29, 2023

Fix race condition issues between the main thread and module threads #12817

Merged

sundb mentioned this pull request Jan 3, 2024

Make RM_Yield thread-safe #12905

Merged

jpmckinney mentioned this pull request Dec 1, 2025

feat: migrate to rapidfort container open-contracting/deploy#587

Open

Adding module api for processing commands during busy jobs and allow flagging the commands that should be handled at this status #9963

Adding module api for processing commands during busy jobs and allow flagging the commands that should be handled at this status #9963

Uh oh!

Conversation

perryitay commented Dec 19, 2021 • edited by oranagra Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MeirShpilraien commented Dec 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oranagra commented Dec 22, 2021

Uh oh!

guybe7 commented Dec 22, 2021

Uh oh!

MeirShpilraien commented Dec 23, 2021

Uh oh!

itamarhaber left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

oranagra commented Jan 18, 2022

Uh oh!

madolson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sundb commented Jan 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oranagra commented Jan 20, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

perryitay commented Dec 19, 2021 •

edited by oranagra

Loading

MeirShpilraien commented Dec 22, 2021 •

edited

Loading

sundb commented Jan 20, 2022 •

edited

Loading