Issues with pub/sub about hiredis-cluster HOT 4 OPEN

Hi, my previous assessment that this would work seem to be wrong..
The problem with pub/sub is that hiredis keeps its callback-info to be able to reuse this for all messages, while redis-cluster currently dont. hiredis-cluster frees its cluster_async_data after each called callback.

One possible fast-fix until this is handled correctly in hiredis-cluster could be to use the hiredis api directly in your connectCallback(). Here you have the redisAsyncContext for the specific node already and instead of iterating all nodes again you could use this redisAsyncContext as in the hiredis tests.
The callback would have a different signature but maybe thats ok?

We also need to findout how to handle this correctly in hiredis-cluster.

from hiredis-cluster.

Thank you. We will try out your suggestion.

With regards to the issue with the PSUBSCRIBE response we mentioned, the null there was because we were reading reply->element[j]->str in eventCb().
Changing that to reply->element[j]->integer has fixed that problem.

from hiredis-cluster.

Some notes of options how to solve this a near future:

• Option 1: Add information in hiredis redisCallback to inform user if the redisCallback-object with the privdata reference will be deleted or kept by hiredis (kept when pubsub).
  This will be used to know if hiredis-clusters cluster_async_data object should be deleted or not.

• Option 2: Like hiredis, check sent commands to find "*SUBSCRIBE" and set a flag in the created cluster_async_data that this callback is used for pubsub. With this knowledge we know when cluster_async_data should be deleted or not. When flagged to be a subscribe callback we should not delete the cluster_async_data since it's a published message, and the callback is reused.

Drawbacks I can think of

• In both options above we dont know when its ok to delete cluster_async_data after an UNSUBSCRIBE has been sent. hiredis dont call the user callback when response to SUBSCRIBE/UNSUNSCRIBE comes..

from hiredis-cluster.

See #27

from hiredis-cluster.