[4.x] Fix how hash slot assignment is retrieved and stored #407
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ladicek
changed the title
|
The test failure is not caused by this PR, it fails on the current 4.x branch too (as well as in #406). |
|
thanks @Ladicek let me fix the build and then you can rebase :-) |
vietj
reviewed
Sep 21, 2023
| } | ||
| } | ||
| } | ||
|
|
||
| private void getSlots(String endpoint, RedisConnection conn, Handler<AsyncResult<Slots>> onGetSlots) { | ||
| private Future<Slots> getSlots() { |
There was a problem hiding this comment.
instead here we should have a context
vietj
reviewed
Sep 21, 2023
| private Future<Slots> getSlots() { | ||
| Slots slots = this.slots.get(); | ||
| if (slots != null) { | ||
| return Future.succeededFuture(slots); |
There was a problem hiding this comment.
and use context.succeededFuture(slot)
vietj
reviewed
Sep 21, 2023
| return Future.succeededFuture(slots); | ||
| } | ||
|
|
||
| Promise<Slots> promise = vertx.promise(); |
vietj
reviewed
Sep 21, 2023
src/main/java/io/vertx/redis/client/impl/RedisClusterClient.java
Outdated
Show resolved
Hide resolved
Previously, the `RedisClusterClient` used to obtain the hash slot assignment as the first step of each `connect()` call. This is fairly expensive and increases the load on the first endpoint in the list (because we target the first endpoint when issuing `CLUSTER SLOTS`). It is also unnecessary. Redis always sends a redirection when the node to which a command is sent is not assigned the hash slot targetted by the command. Until we observe such redirection, the hash slot assignment we observed before is still valid. Hence, we can store the hash slot assignment in the `RedisClusterClient` and reuse it for all `RedisClusterConnection` objects, until the `MOVED` error is seen. In such case, we reset the hash slot assignment so that the next `connect()` call fetches it again. To avoid spurious failures (it could happen that the cluster is resharded such that a command that would fail under the existing hash slot assignment will no longer fail, because the hash slots that were previously assigned to multiple nodes are now assigned to a single node), the hash slot assignment is not kept permanently. Instead, it is treated as a cache with configurable TTL, defaulting to 1 second.
Ladicek
force-pushed
the
fix-cluster-slots-retrieval-4.x
branch
from
f1025a5 to
7a25220
Compare
|
Refactored as discussed on Friday:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #405 to 4.x.