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

SOLR-16951: Cache client pkiAuth headers for a second #1921

Closed
wants to merge 1 commit into from

Conversation

HoustonPutman
Copy link
Contributor

https://issues.apache.org/jira/browse/SOLR-16951

Also increase the TTL from 5 seconds to 10.

This is a WIP for now. probably need to think some more about it.

private volatile ConcurrentHashMap<String, AtomicReference<CachedToken>> cachedV2Tokens =
new ConcurrentHashMap<>();

private static final Duration cacheExpiryTime = Duration.ofSeconds(1);
Copy link
Member

Choose a reason for hiding this comment

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

How about we make this relative to MAX_VALIDITY? like MAX_VALIDITY * 0.5, or MAX_VALIDITY * 0.1 by default?

String token;

private CachedToken(Instant generatedAt, String token) {
this.generatedAt = generatedAt;
Copy link
Member

Choose a reason for hiding this comment

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

not a big deal, but if we just store the expiration time instead of the generation time we don't have to subtract every time

Copy link
Member

Choose a reason for hiding this comment

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

+1 to the above and maybe also add a method isExpired() to simplify the code

Comment on lines +508 to +509
AtomicReference<CachedToken> tokenRef =
cachedV1Tokens.computeIfAbsent(usr, u -> new AtomicReference<>(generateToken(u)));
Copy link
Member

Choose a reason for hiding this comment

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

I'm wondering if we need to consider limiting the size of this map in some way? can the different users be ever growing (probably not with the OOTB authentication, but maybe with plugins?)

assert usr != null;
String s = usr + " " + System.currentTimeMillis();
byte[] payload = s.getBytes(UTF_8);
byte[] payloadCipher = publicKeyHandler.getKeyPair().encrypt(ByteBuffer.wrap(payload));
String base64Cipher = Base64.getEncoder().encodeToString(payloadCipher);
log.trace("generateToken: usr={} token={}", usr, base64Cipher);
return myNodeName + " " + base64Cipher;
return new CachedToken(Instant.now(), myNodeName + " " + base64Cipher);
Copy link
Member

Choose a reason for hiding this comment

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

Instant.now(), could move into the CachedToken constructor, doesn't need to be specified here.

return tokenRef.get().token;
}

private synchronized String getTokenV2(String usr) {
Copy link
Member

Choose a reason for hiding this comment

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

the 2 methods getToken and getTokenV2 are very similar. would you consider unifying into a single one? (one that gets a map and a 'token generator' function)

.map(PKIAuthenticationPlugin.this::generateToken)
.ifPresent(token -> request.header(HEADER, token));
.map(PKIAuthenticationPlugin.this::getToken)
.ifPresent(token -> request.headers(mutable -> mutable.add(HEADER, token)));
Copy link
Member

Choose a reason for hiding this comment

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

minor: maybe 'put' is a better method for this header

private synchronized String getTokenV2(String usr) {
AtomicReference<CachedToken> tokenRef =
cachedV2Tokens.computeIfAbsent(usr, u -> new AtomicReference<>(generateTokenV2(u)));
if (tokenRef.get().generatedAt.isBefore(Instant.now().minus(cacheExpiryTime))) {
Copy link
Member

Choose a reason for hiding this comment

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

just wondering how this performs if it would be a single ConcurrentHashMap#compute method instead of all the locks and checks. is there a benchmark for this change?

Copy link

This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the [email protected] mailing list. Thank you for your contribution!

@github-actions github-actions bot added the stale PR not updated in 60 days label Jan 27, 2024
Copy link

github-actions bot commented Oct 7, 2024

This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active again.

@github-actions github-actions bot added the closed-stale Closed after being stale for 60 days label Oct 7, 2024
@github-actions github-actions bot closed this Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-stale Closed after being stale for 60 days stale PR not updated in 60 days
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants