Closed rovarghe closed 1 year ago
Hey there, thanks for this!
Sorry for not replying yet - just juggling a few things atm. Will try take a proper look by the end of the weekend or early next week! :-)
Closing, a new implementation is underway on the v4 branch 👍
@ptaoussanis
This PR is for review only.
I am trying to take a shot at Issue #76 following your comments in cluster.clj. Not sure if this is on the right track, but a couple of additional things to consider: 1) Keys can move between clusters. This results in a MOVED exception so the operation has to be retried. before which the exception has to be parsed and the new slot:server-port mapping is updated in the cache, OR, a separate update request has to be sent to the server to get the new slot-server tables. I think the latter is the recommended approach at redis.io - since when a slot moves, its likely to be a batch operation and several requests may encounter the error.
2) I didn't quite get how the pooling would work when a MOVED exception is encountered. The connections in the (default) thread pool would be using the original spec. Each MOVED exception, is basically discovering a new spec that has never been seen/declared. So a pool:spec:conn index needs to be maintained I think.