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

Add configurable in-memory caching to the HTTP Credentials Provider #155

Merged
merged 2 commits into from
Sep 23, 2024

Conversation

vagaerg
Copy link
Member

@vagaerg vagaerg commented Sep 20, 2024

No description provided.

@cla-bot cla-bot bot added the cla-signed label Sep 20, 2024
@@ -37,7 +37,6 @@ protected void setup(Binder binder)
HttpCredentialsProvider.class,
innerBinder -> {
configBinder(innerBinder).bindConfig(HttpCredentialsProviderConfig.class);
innerBinder.bind(HttpCredentialsProvider.class);
Copy link
Contributor

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()
Copy link
Contributor

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

Copy link
Member Author

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;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
private AtomicInteger requestCounter;
private final AtomicInteger requestCounter;

@vagaerg vagaerg force-pushed the add-http-creds-caching branch 2 times, most recently from 33bd633 to c2356f7 Compare September 20, 2024 16:23
@@ -37,7 +37,6 @@ protected void setup(Binder binder)
HttpCredentialsProvider.class,
innerBinder -> {
configBinder(innerBinder).bindConfig(HttpCredentialsProviderConfig.class);
innerBinder.bind(HttpCredentialsProvider.class);
Copy link
Member

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()
Copy link
Member

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.

Copy link
Member Author

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.
@vagaerg vagaerg merged commit 6724a1d into trinodb:main Sep 23, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants