Unexpected behavior of UNSUBSCRIBE with cluster mode about vertx-redis-client

[Ladicek]

I think this is intentional. When we SUBSCRIBE, we don't know to which node we're connected, it is selected randomly. So when we want to UNSUBSCRIBE, we need to execute that command on all nodes.

[jabolina]

Yeah, that makes sense to me, a single request to each node. I believe that currently, it sends N times for the same node, where N is the number of slots a node owns.

It looks like in cluster mode from version 7+, pub/sub goes to a slot owner (https://redis.io/docs/interact/pubsub/#sharded-pubsub).

[Ladicek]

Sharded pub/sub is done using SSUBSCRIBE, SUNSUBSCRIBE and SPUBLISH, so that's a different thing. What you have is not sharded. (I recently made a change where the sharded pub/sub commands are treated similarly to classic pub/sub, which was probably a mistake I made without understanding sharded pub/sub properly. I will have to revisit it.)

It seems super unlikely that we would send the command once for each slot, because the number of slots in Redis cluster is 16K. In the reproducing test you made, the cluster has 3 nodes, so I would expect the UNSUBSCRIBE command to be send 3x and hence there would be 3 responses to it. The total number of received messages in the test should IMHO be 5.

[jabolina]

Yeah, that's it. Coming back to the test now:

received msg [subscribe, sub-unsub, 1]
received msg [message, sub-unsub, hello]
received msg [unsubscribe, sub-unsub, 0]
received msg [unsubscribe, sub-unsub, 0]
received msg [unsubscribe, sub-unsub, 0]

One for each node. I believe we can safely close this one. Thanks for the help, and sorry about the noise.

[Ladicek]

Sure thing, thanks for the confirmation!