- 10 Jul, 2023 1 commit
-
-
Oran Agra authored
So far clients being blocked and unblocked by a module command would update the c->woff variable and so WAIT was ineffective and got released without waiting for the command actions to propagate. This seems to have existed since forever, but not for RM_BlockClientOnKeys. It is problematic though to know if the module did or didn't propagate anything in that command, so for now, instead of adding an API, we'll just update the woff to the latest offset when unblocking, this will cause the client to possibly wait excessively, but that's not that bad. (cherry picked from commit 6117f288)
-
- 08 Mar, 2022 1 commit
-
-
guybe7 authored
Deleting a stream while a client is blocked XREADGROUP should unblock the client. The idea is that if a client is blocked via XREADGROUP is different from any other blocking type in the sense that it depends on the existence of both the key and the group. Even if the key is deleted and then revived with XADD it won't help any clients blocked on XREADGROUP because the group no longer exist, so they would fail with -NOGROUP anyway. The conclusion is that it's better to unblock these clients (with error) upon the deletion of the key, rather than waiting for the first XADD. Other changes: 1. Slightly optimize all `serveClientsBlockedOn*` functions by checking `server.blocked_clients_by_type` 2. All `serveClientsBlockedOn*` functions now use a list iterator rather than looking at `listFirst`, relying on `unblockClient` to delete the head of the list. Before this commit, only `serveClientsBlockedOnStreams` used to work like that. 3. bugfix: CLIENT UNBLOCK ERROR should work even if the command doesn't have a timeout_callback (only relevant to module commands)
-
- 30 Dec, 2021 1 commit
-
-
Viktor Söderqvist authored
These exist for quite some time, and are no longer experimental
-
- 28 Nov, 2021 1 commit
-
-
Viktor Söderqvist authored
Writable replicas now no longer use the values of expired keys. Expired keys are deleted when lookupKeyWrite() is used, even on a writable replica. Previously, writable replicas could use the value of an expired key in write commands such as INCR, SUNIONSTORE, etc.. This commit also sorts out the mess around the functions lookupKeyRead() and lookupKeyWrite() so they now indicate what we intend to do with the key and are not affected by the command calling them. Multi-key commands like SUNIONSTORE, ZUNIONSTORE, COPY and SORT with the store option now use lookupKeyRead() for the keys they're reading from (which will not allow reading from logically expired keys). This commit also fixes a bug where PFCOUNT could return a value of an expired key. Test modules commands have their readonly and write flags updated to correctly reflect their lookups for reading or writing. Modules are not required to correctly reflect this in their command flags, but this change is made for consistency since the tests serve as usage examples. Fixes #6842. Fixes #7475.
-
- 19 Oct, 2021 1 commit
-
-
qetu3790 authored
Prevent clients from being blocked forever in cluster when they block with their own module command and the hash slot is migrated to another master at the same time. These will get a redirection message when unblocked. Also, release clients blocked on module commands when cluster is down (same as other blocked clients) This commit adds basic tests for the main (non-cluster) redis test infra that test the cluster. This was done because the cluster test infra can't handle some common test features, but most importantly we only build the test modules with the non-cluster test suite. note that rather than really supporting cluster operations by the test infra, it was added (as dup code) in two files, one for module tests and one for non-modules tests, maybe in the future we'll refactor that. Co-authored-by:
Oran Agra <oran@redislabs.com>
-
- 23 Jan, 2021 1 commit
-
-
Oran Agra authored
1. Valgrind leak in a recent change in a module api test 2. Increase treshold of a RESTORE TTL test 3. Change assertions to use assert_range which prints the values
-
- 22 Jan, 2021 1 commit
-
-
Viktor Söderqvist authored
BLPOP and other blocking list commands can only block on empty keys and LPUSH only wakes up clients when the list is created. Using the module API, it's possible to block on a non-empty key. Unblocking a client blocked on a non-empty list (or zset) can only be done using RedisModule_SignalKeyAsReady(). This commit tests it.
-
- 20 Jan, 2021 1 commit
-
-
guybe7 authored
the test was misleading because the module would actually woke up on a wrong type and re-blocked, while the test name suggests the module doesn't not wake up at all on a wrong type.. i changed the name of the test + added verification that indeed the module wakes up and gets re-blocked after it understand it's the wrong type
-
- 19 Jan, 2021 1 commit
-
-
Viktor Söderqvist authored
This was a regression from #7625 (only in 6.2 RC2). This makes it possible again to implement blocking list and zset commands using the modules API. This commit also includes a test case for the reverse: A module unblocks a client blocked on BLPOP by inserting elements using RedisModule_ListPush(). This already works, but it was untested.
-
- 01 Apr, 2020 1 commit
-
-
Guy Benoish authored
By using a "circular BRPOPLPUSH"-like scenario it was possible the get the same client on db->blocking_keys twice (See comment in moduleTryServeClientBlockedOnKey) The fix was actually already implememnted in moduleTryServeClientBlockedOnKey but it had a bug: the funxction should return 0 or 1 (not OK or ERR) Other changes: 1. Added two commands to blockonkeys.c test module (To reproduce the case described above) 2. Simplify blockonkeys.c in order to make testing easier 3. cast raxSize() to avoid warning with format spec
-
- 30 Dec, 2019 1 commit
-
-
Guy Benoish authored
If a blocked module client times-out (or disconnects, unblocked by CLIENT command, etc.) we need to call moduleUnblockClient in order to free memory allocated by the module sub-system and blocked-client private data Other changes: Made blockedonkeys.tcl tests a bit more aggressive in order to smoke-out potential memory leaks
-
- 04 Nov, 2019 1 commit
-
-
Guy Benoish authored
-