resubscribe
logic looks ignoring sharded Pub/Sub (shardChannels
Set of PubSubEndpoint
)
#2940
Labels
status: good-first-issue
An issue that can only be worked on by brand new contributors
status: help-wanted
An issue that a contributor can help us with
type: bug
A general bug
Milestone
Bug Report
Thank you for adding support for sharded PubSub in the 6.4.0.
Related to that implementation, I would like to confirm about
resubscribe
(subscription recovery after reconnection) behavior.It looks like
resubscribe
handling only non-sharded PubSub subscriptions.Current Behavior
Sharded PubSub subscriptions looks not recovered after disconnection + re-connection, despite Lettuce automatically recovers non-sharded PubSub subscriptions (the recovery behavior is very helpful for applications, and also difficult / error-prone to implement by ourselves).
In the 1457486#diff-73f0c5ac0f7d6d94f8d47e1a75564aa344cbbbd4c91ce786711b5c3673044956,
PubSubEndpoint.shardChannels
(private
) have been added but it looks that variable is private insidePubSubEndpoint
and no any code ofPubSubEndpoint
reading that variable's data. Also implementations ofStatefulRedisPubSubConnectionImpl.resubscribe
andStatefulRedisClusterPubSubConnectionImpl.resubscribe
does not accessingshardChannels
.Input Code
Just make sharded Pub/Sub connection, and wait until some disconnection + re-connection occurs on that environment...
Input Code
Expected behavior/code
As same as non-sharded Pub/Sub, automatically recover sharded Pub/Sub subscriptions when possible to connect to that shard/node.
( May be a bit different logic from non-sharded Pub/Sub needed. Because the SSUBSCRIBE requires living connection to the particular shard's node(s) )
Environment
Possible Solution
(Not tested) Watch the connection's state somehow and manually call
ssubscribe
again by application's logic.Additional context
Because currently I don't have full access to a target environment / Redis cluster, this issue is based on best guess by reading code. I hope this code reading makes some sense...
The text was updated successfully, but these errors were encountered: