-
Notifications
You must be signed in to change notification settings - Fork 7
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
Cache client state #198
Cache client state #198
Conversation
Generate changelog in
|
conjure-runtime/src/client_cache.rs
Outdated
pub struct ClientCache { | ||
inner: Arc<Mutex<Inner>>, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of having this inner field on the public struct? Does it hide your Inner cache implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep!
conjure-runtime/src/client_cache.rs
Outdated
} | ||
|
||
#[derive(Clone)] | ||
pub struct ClientCache { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably worth adding some tests for the ClientCache logic, especially since the evictor logic is a bit tricky
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I think the best route is probably to make the cache generic so I can use a different type than DefaultRawClient for testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that sounds right. If you make the cache key generic it might also make it easier to move that closer to the builder logic, where the builder comes with a method to generate the cache key.
Invalidated by push of 680b66a
Made a few updates
|
pub fn get<T>( | ||
&self, | ||
seed: &T, | ||
get_key: impl FnOnce(&T) -> &K, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_key
and make_value
feel like they should go in new
and not on each invocation to get
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but the only reason I genericized the cache was for the tests, and moving the functions into new would make those a bit more awkward to write.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one small comment on where we place get_key
and make_value
. I think it would be cleaner to put those once on new
and just store them as properties on the cache, kind of like what Caffeine does.
If there's a good reason why that's tough to do, I'm good with merging this as is to unblock.
Before this PR
Every call to
ClientFactory::client
created a new, independent client. This prevented connection sharing between clients made for distinct service types for the same remote service.After this PR
==COMMIT_MSG==
Client state is now cached and shared between clients.
==COMMIT_MSG==
The cache will evict states that are no longer referenced immediately. This matches Dialogue's new behavior as of palantir/dialogue#2194.
Possible downsides?
The cache is currently quite conservative - we could potentially share connections between e.g. clients with differing idempotency settings. An improved setup could be to separate socket-level and other settings and have a separate connection pool cache.
If we add more client settings, there is a risk of forgetting to include them in the cache key. I'm not sure of a good way to avoid that though - maybe storing theThe config fields are now explicitly partitioned between cached and uncached.CacheKey
directly inBuilder
?Closes #45