Skip to content

Fixed hot cache update on calls to Set() #11

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

Merged
merged 1 commit into from
Jan 2, 2025
Merged

Conversation

thrawn01
Copy link
Contributor

@thrawn01 thrawn01 commented Dec 3, 2024

Purpose

@xWiiLLz Reported the hot cache's of remote peers were not updated when calling Set(). mailgun/groupcache#69

This PR fixes a long standing TODO where there was some question if the hot cache should always be updated on calls to Set().

Resolution

We should ALWAYS update the main cache and delete the key from the hot cache when Set() is called.

Rationale

We do not know when the owning peer may switch to a different node due to cluster topography changes. If an owner belongs to a different node the instant after Set() completes, calls to Get(), consulting the hot cache, may find the previously set value.

Because we don't know which or when a node in the cluster may become the owner, every node in the cluster should be treated identically.

I left the hotCache boolean in the signature of Set() as I didn't want to make a version breaking change.

@thrawn01 thrawn01 force-pushed the thrawn/set-hotcache branch from de04640 to 3548057 Compare December 4, 2024 15:46
Copy link
Collaborator

@Baliedge Baliedge left a comment

Choose a reason for hiding this comment

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

LGTM. Just a little nit to pick.

@@ -6,7 +6,8 @@ $(GOLANGCI_LINT): ## Download Go linter

.PHONY: ci
ci: tidy lint test
go mod tidy && git diff --exit-code
@echo
@echo "\033[32mEVERYTHING PASSED!\033[0m"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Color terminals cannot be assumed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems like this might have been true 10+ years ago, The worst that could happen is they get some escape codes in their output. I don't think we should optimize for the odd chance someone is running this on a TSR compatible terminal.

@thrawn01 thrawn01 merged commit ce20af8 into main Jan 2, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants