We want to standardize the way that admin users can describe and interact with the client commands. We are proposing to generalize the filters introduced in CLIENT KILL so that it also works to count and list clients as well.
The following commands could work with the same set of filters.
- CLIENT COUNT [filters...] (New command suggested)
- CLIENT KILL [filters...]
- CLIENT LIST [filters...]
The supported filters are to be decided. Suggestions, including already existing filters:
More filter suggestions that came up during discussions:
- IP or CLIENT-IP, or allow overloaded
ADDR ip. (The existing filter syntax ADDR ip:port is not very useful, because the client's port is ephemeral and will change for each connection.)
- LIB-NAME
- LIB-VER
- DB number
- TOT-NET-IN bytes
- TOT-NET-OUT bytes
In Redis we also discussed adding a new command, CLIENT DESCRIBE, will also introduce the notion of selectors. Selectors allow you to scope down the fields you are interested in.
CLIENT DESCRIBE SELECT ID ADDR FILTER MIN-AGE 100
We want to standardize the way that admin users can describe and interact with the client commands. We are proposing to generalize the filters introduced in CLIENT KILL so that it also works to count and list clients as well.
The following commands could work with the same set of filters.
The supported filters are to be decided. Suggestions, including already existing filters:
for compatibility reasons with client list, client-id must be specified last.<shard channel the client must subscribe to>(Needed?)CLIENT LIST FLAGS "bPt".MIN-IDLE) minimum idle time of the client.More filter suggestions that came up during discussions:
ADDR ip. (The existing filter syntaxADDR ip:portis not very useful, because the client's port is ephemeral and will change for each connection.)In Redis we also discussed adding a new command,
CLIENT DESCRIBE, will also introduce the notion of selectors. Selectors allow you to scope down the fields you are interested in.