Skip to content
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

Use value object for topology caching #2989

Closed
wants to merge 2 commits into from
Closed

Use value object for topology caching #2989

wants to merge 2 commits into from

Conversation

mp911de
Copy link
Member

@mp911de mp911de commented Sep 11, 2024

We now use a value object for caching the topology to avoid races in updating the cache timestamp.

Also, we set the cache timestamp after obtaining the topology to avoid that I/O latency expires the topology cache.

Closes #2986

We now use a value object for caching the topology to avoid races in updating the cache timestamp.

Also, we set the cache timestamp after obtaining the topology to avoid that I/O latency expires the topology cache.

Closes #2986
@mp911de mp911de added the type: bug A general bug label Sep 11, 2024
@mp911de mp911de added this to the 3.3.4 (2024.0.4) milestone Sep 11, 2024
Comment on lines +844 to +845
if (shouldUseCachedValue(topology)) {
return topology;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the previous shouldUseCachedValue() would no longer be called in the patch targeting 3.3.4 so I was wondering if it makes senes to keep the arrangement stable for the SR and changing it for the 3.4 version.
For 3.3.4 we could have

protected boolean shouldUseCachedValue() {
	return shouldUseCachedValue(cached);
}

and call the old method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to apply these changes in the merge.

* @since 3.3.4
*/
protected boolean shouldUseCachedValue(@Nullable JedisClusterTopology topology) {
return topology != null && topology.getTime() + cacheTimeMs > System.currentTimeMillis();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could move the cacheTimeMs to the JedisClusterTopology having a package private method maxTime that does the calculation.

christophstrobl pushed a commit that referenced this pull request Sep 11, 2024
We now use a value object for caching the topology to avoid races in updating the cache timestamp.

Also, we set the cache timestamp after obtaining the topology to avoid that I/O latency expires the topology cache.

Closes: #2986
Original Pull Request: #2989
christophstrobl added a commit that referenced this pull request Sep 11, 2024
Move maxTime calculation for topology refresh to and delegate shouldUseCachedValue() to newly introduced overload.

Original Pull Request: #2989
christophstrobl pushed a commit that referenced this pull request Sep 11, 2024
We now use a value object for caching the topology to avoid races in updating the cache timestamp.

Also, we set the cache timestamp after obtaining the topology to avoid that I/O latency expires the topology cache.

Closes: #2986
Original Pull Request: #2989
christophstrobl added a commit that referenced this pull request Sep 11, 2024
Move maxTime calculation for topology refresh to and delegate shouldUseCachedValue() to newly introduced overload.
Retain application flow as much as possible.

Original Pull Request: #2989
@christophstrobl christophstrobl deleted the issue/2986 branch September 11, 2024 11:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Race condition in JedisClusterTopologyProvider
2 participants