-
Notifications
You must be signed in to change notification settings - Fork 23.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] RedisModule_UnblockClient behaviour does not match the documentation #7879
Comments
hello @manast
in the first case, when you block the client by calling RM_BlockClient (which doesn't have a privdata argument). when you unblock using RM_UnblockClient you provide a privdata which is accessible in the reply_callback via RedisModule_GetBlockedClientPrivateData in the second case you call RM_BlockClientOnKeys and you may provide a privdata. if you choose to unblock the client with RM_UnblockClient (which also takes a privdata) none of the privdata is used and the client is released with the timeout_callback (the logic is that if you chose to unblock a blocked-on-keys-client with RM_UnblockClient instead of RM_SIgnalKeyAsReady it means that something is wrong) general comment: the privdata (both the one provided in RM_UnblockClient and optionally in RM_BlockClientOnKeys) is not accessible in the timeout_callback (only in the reply_callback and disconnect_callback) so yes, there is a problem with the docs. the section you sent should be corrected to:
we should change the doc of RedisModule_GetBlockedClientPrivateData:
|
yeah, basically I knew already all you wrote above after many tests and investigations. The problem is that as I show in #7880 RM_SignalKeyAsReady does not work when called from a timer callback or from a thread (probably the timer callback is called from a thread too it is my guessing). So I am forced to use RM_UnblockClient and of course is a bit inconvenient not having access to the privdata anymore. |
it seems to me the "problem" here is that there's no access to privdata from the timeout callback (after #7880 is cleared that won't be a problem for you as you will not need to call RM_UnblockClient any more) TBH i don't really see an advantage on accessing privdata in the timeout_callback... after all, it's just a timeout, why would you need privdata? @oranagra thoughts? |
I think it's always better if any callback would get a privdata. |
yes it's very simple, we just need to assign |
Normally it is a timeout but when you call UnblockClient manually even though it calls Timeout it has been called before the actual timeout time has passed. What is a bit confusing to me is why UnblockClient has a different behaviour when using RedisModule_BlockClientOnKeys than when used with RM_BlockClient. |
the reason is that under normal circumstances a client that was blocked with BlockOnKeys should be released with SignalKeyAsReady and not by UnblockClient. when you use BlockClient you don't provide privdata; when you unblock it you do (this is usually the case for threads: the worker thread has some information that should be in the reply of the unblocked client). when you use BlockClientOnKeys you provide a privdata (usually has to do with the target state of the key); when you unblock it (hopefully with SignalKeyAsReady) you don't provide privdata. using UnblockClient for a client blocked on keys is undesired and the only reason it exists is so that the module can do a proper cleanup in case it is unloaded etc. i know it's a bit confusing but just remember the pairs BlockClient/UnblockClient and BlockClientOnKeys/SignalKeyAsReady |
Fix redis#7879 redis#7880 1. Fix some comments 2. Make sure blocked-on-keys client privdata is accessible from withing the timeout callback 3. Handle blocked clients in beforeSleep - In case a key becomses "ready" outside of processCommand
Fix redis#7879 redis#7880 1. Fix some comments 2. Make sure blocked-on-keys client privdata is accessible from withing the timeout callback 3. Handle blocked clients in beforeSleep - In case a key becomses "ready" outside of processCommand
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
Describe the bug
sorry if this text is a bit confusing, it has been many hours of debugging until I realized this may be an issue with redis.
The documentation for
RedisModule_UnblockClient
is either incorrect or something does not add up in how to use the function when blocking a client withRedisModule_BlockClientOnKeys
.Due to issue #7878 I am using the function above as a workaround for unblocking the client. In this case the client is unblocked as expected, and this time as the documentation states (confusingly since it first talks about reply callback then clarifies that it is the timeout callback) it calls the Timeout callback instead of the reply callback (https://redis.io/topics/modules-api-ref)
The problem is that the signature of the timeout callback is this one (in zig):
There is no privdata argument in the signature, so that must be a mismatch with the documentation. But the biggest problem is that if you try to get the privdata with
pData will always be NULL. Therefore it becomes impossible to access the privdata in this scenario.
I am missing something?
The text was updated successfully, but these errors were encountered: