muralibasani commented on PR #24093: URL: https://github.com/apache/kafka/pull/24093#issuecomment-6687406871
> @muralibasani Thanks for the review! The`getTokens()` recomputes the HMAC for every returned token on each DescribeDelegationToken request, and reading it from the cache would avoid that. We can file a follow-up JIRA. That follow-up will have to handle the case you raised on `removeToken()`: once the cache returns its own `DelegationToken` objects, the hmac array becomes reachable outside the cache. So the follow-up should hand out copies, or keep the base64 string computed at insert time. Agree. We can keep it inside DelegationTokenCache rather than adding defensive copies to DelegationToken, since that class is public API (common.security.token.delegation is in the javadoc set) and changing hmac() semantics there isn't worth the debate. Basically we store the Base64 hmac computed at insert time (it's already the hmacTokenIdCache key, so removeToken stays symmetric with addToken), and have a new accessor return fresh DelegationTokens decoded from it. Then getTokens() can use it instead of recomputing HmacSHA512. I will create/take up the follow up JIRA, and link this thread. -- 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]
