Skip to content

Hash keys locally rather than call cluster keyslot #2159

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

upthewaterspout
Copy link
Contributor

Changing the remaining commands in JedisClusterKeyCommands to use the
topology's getKeyServingMasterNode to find the node of key, rather than calling
connection.clusterGetNodeForKey. clusterGetNodeForKey was making a cluster
keyslot call to the server to hash the key, rather than hashing it locally.

Closes: #2156

  • You have read the Spring Data contribution guidelines.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

Changing the remaining commands in JedisClusterKeyCommands to use the
topology's getKeyServingMasterNode to find the node of key, rather than calling
connection.clusterGetNodeForKey. clusterGetNodeForKey was making a cluster
keyslot call to the server to hash the key, rather than hashing it locally.

Closes: spring-projects#2156
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 8, 2021
@mp911de mp911de self-assigned this Sep 14, 2021
@mp911de mp911de added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 14, 2021
@mp911de mp911de added this to the 2.5.5 (2021.0.5) milestone Sep 14, 2021
mp911de pushed a commit that referenced this pull request Sep 14, 2021
Changing the remaining commands in JedisClusterKeyCommands to use the
topology's getKeyServingMasterNode to find the node of key, rather than calling
connection.clusterGetNodeForKey. clusterGetNodeForKey was making a cluster
keyslot call to the server to hash the key, rather than hashing it locally.

Closes: #2156
Original pull request: #2159.
mp911de added a commit that referenced this pull request Sep 14, 2021
Revert changes in JedisClusterKeyCommands. Switch clusterGetNodeForKey method to calculate the slot locally.

See #2156
Original pull request: #2159.
mp911de pushed a commit that referenced this pull request Sep 14, 2021
Changing the remaining commands in JedisClusterKeyCommands to use the
topology's getKeyServingMasterNode to find the node of key, rather than calling
connection.clusterGetNodeForKey. clusterGetNodeForKey was making a cluster
keyslot call to the server to hash the key, rather than hashing it locally.

Closes: #2156
Original pull request: #2159.
mp911de added a commit that referenced this pull request Sep 14, 2021
Revert changes in JedisClusterKeyCommands. Switch clusterGetNodeForKey method to calculate the slot locally.

See #2156
Original pull request: #2159.
@mp911de
Copy link
Member

mp911de commented Sep 14, 2021

I think it's easier to switch clusterGetNodeForKey to calculate the slot locally instead of obtaining the TopologyProvider. We have the same behavior already in place for Lettuce, so it makes sense to align the Jedis implementation.

Thank you for your contribution. That's merged, polished, and backported now.

@mp911de mp911de closed this Sep 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JedisClusterKeyCommands makes extra KEYSLOT calls to the server
3 participants