dlmarion commented on code in PR #2707:
URL: https://github.com/apache/accumulo/pull/2707#discussion_r874711539
##########
server/base/src/main/java/org/apache/accumulo/server/security/handler/ZKSecurityTool.java:
##########
@@ -114,16 +119,34 @@ public static byte[] createPass(byte[] password) throws
AccumuloException {
return cryptHash.getBytes(UTF_8);
}
+ private static final Cache<String,String> CRYPT_PASSWORD_CACHE =
Caffeine.newBuilder()
+ .scheduler(Scheduler.systemScheduler()).expireAfterWrite(3,
TimeUnit.SECONDS).build();
Review Comment:
> For this to be of benefit, we'd have to be creating a lot of connections
pretty quickly. I'm not sure how realistic that would be.
I think that is what is described in #2700 as part of a test. I could see
real work implications, typically on application startup where you have a
thundering herd type situation.
> Wouldn't we want expireAfterAccess rather than write? If it's still
frequently being accessed, it'd be good to keep it around, regardless of the
last time it was written to the cache.
This was based on an earlier comment about have really short times in the
cache. I think at this point it could be longer and based on access rather than
write.
> I'm not sure this is worth it. The underlying issue seems highly dependent
on specific JVM versions, and specific JCE providers and their native
instruction hardware optimizations.
I would agree, but I would also say that we are doing work that we might not
have to do.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
