Provide added redis calls for JedisCluster to enable directing to single machine commands

[allanwax]

Doing a ping() on the cluster could be interpreted as meaningless and currently it will fail since no key is provided in the call. We should (perhaps) overload ping() and similar commands to accept parameters that allow you to direct the command to a certain machine. For example.

ping(String key): hash the key an pick the machine/slot associated with the key. Then send a ping() to it.

ping(int slot): send a ping() to the machine currently handling that slot.

Using this I can direct things to a single redis instance that does not make sense as a cluster..

Other possible candidates: blpop, brpop, echo, quit, flushdb, dbsize, select, etc.

[allanwax]

Being able to send a bgrewiteaof to a specific machine would be really nice.

[HeartSaVioR]

I'd like to delegate it until Redis Cluster GA version will be released.
Redis Cluster is still not yet RC, so it may cover our issue - how to send non target instance deterministic commands - later.

[allanwax]

Redis Cluster is now RC1

[HeartSaVioR]

Yeah, I know about RC1, and I know there's not resolved.
I think it is due to Redis Cluster.
Think about sending command with "not yet fully synchronized (may be broken)" slot-instance cache.
We can't be safe until Redis Cluster provides those commands with slot or key parameter (for MOVED, ASK).
Or we should always rebuild cache when executing those commands, which I really wish to avoid.

[HeartSaVioR]

I just post issue to Google Groups now.
https://groups.google.com/d/msg/redis-db/s7EPzAQpuLo/lEeFZyL3TusJ

[sazzad16]

Now it's possible to direct node specific commands by getting nodes using getClusterNodes(). It wasn't available till the last commit before this issue. Closing this issue.

[allanwax]

@sazzad16 Having a work-around by processing the node information is not the same as providing clean functionality. I would have liked to have seen this discussed more before closing the ticket.

[sazzad16]

@HeartSaVioR @marcosnils WDYT?

[marcosnils]

@allanwax do you have a current use-case for this specifically right now?. I haven't seen so many requests for something like this and taking in consideration that a key and a slot can possibly migrate nodes (scaling or resilience), I'm not completely convinced about allowing something like this.

IMHO I prefer to stick to getClusterNodes unless there's a very useful use-case.

[allanwax]

@marcosnils I have and continue to have a use for this case. One of our redis clusters is 12 masters and 12 slaves. To improve performance we use the slaves in readonly mode to get information and writes go as normal to the masters. We are tolerant of data being stale or non-existant in the slave. To make this happen properly we have to periodically get the cluster nodes, process the information, taking into account that the information has changed between version 3 and 4 of redis cluster, and make the right decisions as to what to do and where to send it. It would be much easier to ping the slave when we know the slave, to know whether it is probable that it is safe to do an operation, without knowing the underlying details and do our operations.

However, this is a specific use and I was trying to get discussion on making it easier to surface specific information on the nodes without having to parse the result string.

That said, what we have works (out of necessity) and I don't see the need to expend great effort for this.