KNOX-2658 - Skipping in-memory lookup while fetching expiration/metadata for a token#490
Conversation
|
Cc. @zeroflag |
|
LGTM |
moresandeep
left a comment
There was a problem hiding this comment.
Github does not let me click on line numbers that have not changed so adding my comments here. Why do we have some places that use in-memory implementation and some places that do not? it is a bit confusing.
I think instead of removing the token completely can we adjust the TTL just for the metadata in case of JDBC to be short, say 3-5 mins and we can have that as a "margin of error". Or instead of removing the code, use a switch to figure out when HA is enabled so that non-HA JDBC implementations can still benefit from the cache performance. Thoughts?
|
Thanks, @moresandeep for the detailed comment. Let me try to answer your questions.
I tried to keep the in-memory lookups where we fetch data that cannot be changed. So that it's gonna be the same on each node all the time (until the token is removed/expired).
I'd the idea of replacing the current |
I see, I am cool with it knowing this has been discussed and will be addressed in the future patches :) |
|
…ation/metadata for a token (apache#490) Change-Id: I9836e03efd4d5e37ad7e30ea9806119910b5e7dc
…g expiration/metadata for a token (apache#490)" into cdpd-master
What changes were proposed in this pull request?
As described in the JIRA; in-memory lookup is skipped in JDBC token state service while fetching token expiration or metadata. Instead, we go directly to the DB in this implementation.
Since those queries are simple (there is no table join involved) and they rely on indexed columns the is no significant performance issue.
How was this patch tested?
Updated JUnit test cases and repeated the same steps as described in the JIRA. With my fix, the disabled authentication request fails on node 2 like this: