-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add configurable in-memory caching to the HTTP Credentials Provider #155
Conversation
@@ -37,7 +37,6 @@ protected void setup(Binder binder) | |||
HttpCredentialsProvider.class, | |||
innerBinder -> { | |||
configBinder(innerBinder).bindConfig(HttpCredentialsProviderConfig.class); | |||
innerBinder.bind(HttpCredentialsProvider.class); |
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.
Good catch!
@@ -57,8 +66,16 @@ public static class Filter | |||
public TestingTrinoAwsProxyServer.Builder filter(TestingTrinoAwsProxyServer.Builder builder) | |||
{ | |||
TestingHttpServer httpCredentialsServer; | |||
Map<String, String> expectedHeaders = ImmutableMap.<String, String>builder() |
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.
nit: could we use ImmutableMap.of(...)
? Its less verbose
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.
I usually tend to prefer using the builder if there are more than 1 or 2 entries. The .of(...)
syntax gets a bit messy IMHO above that and you end up relying on formatting to keep each key & its value on the same line, it otherwise is quite unreadable.
No strong opinion, happy to change it if you prefer!
} | ||
|
||
private static class HttpCredentialsServlet | ||
extends HttpServlet | ||
{ | ||
private final Map<String, String> expectedHeaders; | ||
private AtomicInteger requestCounter; |
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.
private AtomicInteger requestCounter; | |
private final AtomicInteger requestCounter; |
33bd633
to
c2356f7
Compare
@@ -37,7 +37,6 @@ protected void setup(Binder binder) | |||
HttpCredentialsProvider.class, | |||
innerBinder -> { | |||
configBinder(innerBinder).bindConfig(HttpCredentialsProviderConfig.class); | |||
innerBinder.bind(HttpCredentialsProvider.class); |
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.
Consider a separate commit for this with an explanation
@@ -48,13 +60,29 @@ public HttpCredentialsProvider(@ForHttpCredentialsProvider HttpClient httpClient | |||
this.jsonCodec = requireNonNull(jsonCodec, "jsonCodec is null"); | |||
this.httpCredentialsProviderEndpoint = config.getEndpoint(); | |||
this.httpHeaders = ImmutableMap.copyOf(config.getHttpHeaders()); | |||
this.credentialsCache = Caffeine.newBuilder() |
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.
If cacheTtl is zero, we wouldn't build or use the cache at all. i.e. it should be Optional
.
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.
I was trying to use a zero-sized cache as a no-op, since it handles the cases where either the TTL or the max size are zero (either of which should result in no caching) nicely.
I agree it's perhaps a bit hacky, will change
credentialsProviderModule already binds the interface to a provider, we do not need to bind our implementation again. This was resulting in multiple instantiation.
c2356f7
to
a5132f7
Compare
No description provided.