Hi,
Right now blpop x 0 followed by lpush x 42 shows up in MONITOR as:
1685565207.356311 [0 127.0.0.1:44574] "blpop" "x" "0"
1685565227.593105 [0 127.0.0.1:35492] "lpush" "x" "42"
However, an argument can be made that blpop should show up after lpush. The blocking pop is effectively executed after the lpush: once data has become available in list x.
blpop showing after would also align with the new (7.2+) semantics of total_commands_processed for blocking commands. Change was introduced in this commit. Before, total_commands_processed increased right away; now, total_commands_processed increases only after they have been unblocked.
Question: would it be possible to change MONITOR to that behaviour? (I have a use case for knowing the true order of execution)
Comment From: enjoy-binbin
maybe somehow related with #11412, we will discuss them later
Comment From: hpatro
I believe there are two set of usecases in MONITOR command:
- Order in which commands were received by the server. (good to observe/debug the commands arriving from application).
- Order in which commands got executed by the server. (good to get the timestamped ordered set of command executed on the server).
I guess we should support both of these use cases and not pick one over other.
Comment From: knggk
If we're keeping both usecases, maybe the new one can be behind an extra argument, maybe monitor exec-order ?
Comment From: hpatro
@knggk May be add an optional parameter to the command like the following.
MONITOR [TYPE RECV|EXEC]
If TYPE argument isn't provided, it would still behave as default i.e. output in the order of command received.
@redis/core-team What are you thoughts on this ?
Comment From: madolson
@ranshid Also want to loop you in for your input.
I think strictly from a compatibility perspective, the default is the behavior we need to maintain. Since before our refactoring, the command was sent to monitors before it was executed. I do agree now it's a bit weird, since BLPOP is registered but executed at a different time. We've talked about various improvements to monitor, I think adding something like flags makes sense for monitor to determine how and what is shown. So MONITOR EXEC-ORDER makes sense to me.
Comment From: madolson
FYI, I moved this from triage to backlog, since I think it's more of a feature than a bug.
Comment From: oranagra
I think that currently MONITOR is mostly used as a debug command, and should be kept as is (the order of when commands arrived to redis). if you need to know the order in which command are executed, you can either tap into the replication or AOF stream. FYI, how to use REPLCONF to skip the rdb part: https://github.com/redis/redis/blob/813924b4c36856b2c2ca6f6cc31ecc732ec74f4a/src/redis-cli.c#L9887
regarding improving the MONITOR, we have a ton of other features we wanna add there, and we don't want to add them incrementally, so all these requests are waiting till we completely re-design this command. i've listed them here (added this one): https://github.com/redis/redis/issues/6321#issuecomment-1175062204
Comment From: knggk
I think that currently MONITOR is mostly used as a debug command, and should be kept as is (the order of when commands arrived to redis). if you need to know the order in which command are executed, you can either tap into the replication or AOF stream. FYI, how to use REPLCONF to skip the rdb part:
https://github.com/redis/redis/blob/813924b4c36856b2c2ca6f6cc31ecc732ec74f4a/src/redis-cli.c#L9887
regarding improving the MONITOR, we have a ton of other features we wanna add there, and we don't want to add them incrementally, so all these requests are waiting till we completely re-design this command. i've listed them here (added this one): #6321 (comment)
One limit of using replication is that it only has mutative commands, sometimes rewritten compared to what client has submitted. monitor exec-order could show client commands, including non-mutative ones. Thank you for adding it to the list :)