Support Blocking a Client on Keyspace Event Notification #1819
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yairgott
changed the title
yairgott
force-pushed
the
client_block
branch
4 times, most recently
from
a064f39 to
74cb5e4
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #1819 +/- ##
============================================
- Coverage 70.99% 70.99% -0.01%
============================================
Files 123 123
Lines 65651 65707 +56
============================================
+ Hits 46609 46648 +39
- Misses 19042 19059 +17
🚀 New features to boost your workflow:
|
enjoy-binbin
reviewed
Mar 6, 2025
enjoy-binbin
reviewed
Mar 6, 2025
enjoy-binbin
reviewed
Mar 6, 2025
madolson
reviewed
Mar 6, 2025
QuChen88
reviewed
Mar 6, 2025
QuChen88
reviewed
Mar 6, 2025
QuChen88
reviewed
Mar 6, 2025
QuChen88
reviewed
Mar 6, 2025
yairgott
force-pushed
the
client_block
branch
3 times, most recently
from
2428ae0 to
7c9cff2
Compare
madolson
reviewed
Mar 7, 2025
yairgott
force-pushed
the
client_block
branch
9 times, most recently
from
dd60c6a to
0445d46
Compare
This change enhances user experience and consistency by allowing a module to block a client on keyspace event notifications. Consistency is improved by ensuring that reads after writes on the same connection yield expected results. For example, in ValkeySearch, mutations processed earlier on the same connection will be available for search. The implementation extends `VM_BlockClient` to support blocking clients on keyspace event notifications. Internal clients, LUA clients, clients issueing multi exec and those with the `deny_blocking` flag set are not blocked. Once blocked, a client’s reply is withheld until it is explicitly unblocked. Signed-off-by: yairgott <[email protected]>
madolson
reviewed
Mar 7, 2025
Co-authored-by: Madelyn Olson <[email protected]> Signed-off-by: Yair Gottdenker <[email protected]>
Co-authored-by: Madelyn Olson <[email protected]> Signed-off-by: Yair Gottdenker <[email protected]> Signed-off-by: yairgott <[email protected]>
|
@valkey-io/core-team This API is a bit late to be added. The feature adds a new functionality to using keyspace notifications, allowing them to block clients. The goal is to provide read and after write consistency for the VSS module. There are two different ways to provide this guarantee, either block the write until it's visible in the index or block the read until all pending writes were ingested. The search module preferred to use the blocking of the write approach, but need an API to block the writes. @murphyjacob4 Will follow up to see if there is a away to avoid this new functionality. |
QuChen88
reviewed
Mar 18, 2025
| @@ -112,7 +113,7 @@ void notifyKeyspaceEvent(int type, char *event, robj *key, int dbid) { | |||
| * This bypasses the notifications configuration, but the module engine | |||
| * will only call event subscribers if the event type matches the types | |||
| * they are interested in. */ | |||
| moduleNotifyKeyspaceEvent(type, event, key, dbid); | |||
| moduleNotifyKeyspaceEvent(c, type, event, key, dbid); | |||
There was a problem hiding this comment.
Can you simply use server.current_client when you invoke this method? That way you don't need to pass in client* into notifyKeyspaceEvent().
QuChen88
reviewed
Mar 18, 2025
| @@ -8880,8 +8924,14 @@ void moduleNotifyKeyspaceEvent(int type, const char *event, robj *key, int dbid) | |||
| if ((sub->event_mask & type) && | |||
| (sub->active == 0 || (sub->module->options & VALKEYMODULE_OPTIONS_ALLOW_NESTED_KEYSPACE_NOTIFICATIONS))) { | |||
| ValkeyModuleCtx ctx; | |||
| moduleCreateContext(&ctx, sub->module, VALKEYMODULE_CTX_TEMP_CLIENT); | |||
| selectDb(ctx.client, dbid); | |||
| if (c == NULL) { | |||
There was a problem hiding this comment.
Rather than passing in client* to this module API, can you simply check if server.current_client is NULL or not?
Or... maybe check server.executing_client if you want to cover the case of a Lua script.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change enhances user experience and consistency by allowing a module to block a client on keyspace event notifications. Consistency is improved by allowing that reads after writes on the same connection yield expected results. For example, in ValkeySearch, mutations processed earlier on the same connection will be available for search.
The implementation extends
VM_BlockClientto support blocking clients on keyspace event notifications. Internal clients, LUA clients, clients issueing multi exec and those with thedeny_blockingflag set are not blocked. Once blocked, a client’s reply is withheld until it is explicitly unblocked.