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

rls: move the data cache implementation into the rls package #5060

Merged
merged 5 commits into from
Dec 22, 2021

Conversation

easwars
Copy link
Contributor

@easwars easwars commented Dec 15, 2021

Summary of changes:

  • Move data cache implementation from balancer/rls/internal/cache/cache.go to balancer/rls/internal/cache.go
    • The data cache implementation is very tightly coupled with certain aspects of the LB policy. So, it does not make sense to have it in a separate package.
  • Also include the childPolicyWrapper implementation here since it is referenced by the data cache

Other changes to the data cache implementation:

  • Remove the lock from the cache entry
  • Store a list of child policy wrappers corresponding to the targets received in the RLS response
  • Implement the following additional functionality
    • resize the cache
      • this is used when the LB policy config specifies a new cache size
    • evict expired entries
      • this is invoked periodically by the LB policy
    • reset backoff state
      • this is invoked by the LB policy when the control channel transitions back to READY

RELEASE NOTES: n/a

@easwars easwars added the Type: Feature New features or improvements in behavior label Dec 15, 2021
@easwars easwars added this to the 1.44 Release milestone Dec 15, 2021
@easwars easwars requested a review from dfawley December 15, 2021 18:20
@easwars
Copy link
Contributor Author

easwars commented Dec 15, 2021

@zasweq

balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
Comment on lines 112 to 115
// callback provided by the LB policy to be notified when the backoff timer
// expires. This will trigger a new picker to be returned to gRPC, to force
// queued up RPCs to be retried.
callback func()
Copy link
Member

Choose a reason for hiding this comment

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

Can this be done along with timer via time.AfterFunc()?

I don't see where this actually does anything (yet?).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This callback needs to be invoked not only when the timer expires, but also when the LB policy explicitly resets the backoff state. This happens when the control channel moves back to READY and the LB policy invokes the resetBackoffState method on the cache.

Copy link
Member

Choose a reason for hiding this comment

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

Update comment to match? It says it's invoked when the timer expires but not anything else.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually what I said was wrong. This callback is only invoked when the backoff timer expires. And it is invoked via a time.AfterFunc() which I just now changed to directly call the method on the LB policy which sends a new picker. See: https://github.com/easwars/grpc-go/blob/rls_master/balancer/rls/internal/picker.go#L329

I think at some point in time, I was using the same field for eviction callback and backoff timer expiry (not able to correctly recollect). But for some reason, I needed to be able to pass different callbacks. But that is not the case anymore. So, I'm totally getting rid of this field.

Thanks.

balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
// evicted. This is important to the RLS LB policy which would send a new picker
// on the channel to re-process any RPCs queued as a result of this backoff
// timer.
func (dc *dataCache) resize(size int64) bool {
Copy link
Member

Choose a reason for hiding this comment

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

It might be a good idea to name the return value since it's not obvious (without reading the comment above) what it should mean.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

updatePicker was the best name i could think of for the return value. Let me know if you have a better one.

Copy link
Member

Choose a reason for hiding this comment

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

I was thinking backoffCanceled like the existing variable name, but either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
balancer/rls/internal/cache.go Outdated Show resolved Hide resolved
balancer/rls/internal/child_policy.go Outdated Show resolved Hide resolved
balancer/rls/internal/child_policy.go Outdated Show resolved Hide resolved
@dfawley dfawley assigned easwars and unassigned dfawley Dec 21, 2021
- rename eviction callback in the cache entry
- rename targetSize to maxSize in the cache entry
- use named result parameters for certain dataCache methods
- directly initialize childPolicyWrapper state
- use base.ErrPicker instead of a new lamePicker type
@easwars easwars assigned dfawley and unassigned easwars Dec 21, 2021
@easwars
Copy link
Contributor Author

easwars commented Dec 21, 2021

Thanks for the review !

- remove `callback` field from `backoffState`
return e.Value.(cacheKey)
}

func (l *lru) iterateAndRun(f func(cacheKey)) {
Copy link
Member

Choose a reason for hiding this comment

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

You might want to document what this function can and cannot be used for. For instance, deletions of the current key from l.ll are allowed, but reordering is not, and deleting the element immediately after the current key would be very bad.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Comment on lines 32 to 36
{path: "0", keys: "0"},
{path: "1", keys: "1"},
{path: "2", keys: "2"},
{path: "3", keys: "3"},
{path: "4", keys: "4"},
Copy link
Member

Choose a reason for hiding this comment

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

Can you change the keys to "a"-"e" just to make sure there are differences between them and the paths?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@dfawley dfawley assigned easwars and unassigned dfawley Dec 22, 2021
@easwars easwars merged commit b3d19ef into grpc:master Dec 22, 2021
@easwars easwars deleted the rls_cache_changes branch March 21, 2022 21:20
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Feature New features or improvements in behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants