[
https://issues.apache.org/jira/browse/KNOX-2658?focusedWorklogId=647837&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-647837
]
ASF GitHub Bot logged work on KNOX-2658:
----------------------------------------
Author: ASF GitHub Bot
Created on: 08/Sep/21 09:16
Start Date: 08/Sep/21 09:16
Worklog Time Spent: 10m
Work Description: smolnar82 commented on pull request #490:
URL: https://github.com/apache/knox/pull/490#issuecomment-915064438
Thanks, @moresandeep for the detailed comment. Let me try to answer your
questions.
> 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 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 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?
I'd the idea of replacing the current `ConcurrentHashMap` caches into
`Caffeine.Cache` instances but we would still have an issue with eventual
consistency within the configured entry TTL in those caches ("margin of
error"). I discussed this approach with @zeroflag and we felt that it'd be
pre-mature optimization that can be added later if we hit any performance
issues. On the other hand, I'm open to re-evaluate that area if we insist this
has to be done now.
--
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]
Issue Time Tracking
-------------------
Worklog Id: (was: 647837)
Time Spent: 40m (was: 0.5h)
> JDBCTokenStateService is not HA-compatible
> ------------------------------------------
>
> Key: KNOX-2658
> URL: https://issues.apache.org/jira/browse/KNOX-2658
> Project: Apache Knox
> Issue Type: Task
> Components: Server
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Critical
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In case of Knox HA deployments, the JDBC token state service cannot guarantee
> that expiration time and metadata-related information (e.g. the enabled flag)
> is up-to-date.
> For instance:
> # a token is created on node 1 -> the in-memory storage in
> DefaultTokenStateService will have all information and the DB will also
> contain everything properly
> # the token is used on node 2 for authentication purposes -> since token
> metadata is not yet available in-memory then first we'll look-up the missing
> piece of information in the DB and then update the in-memory cache in
> DefaultTokenStateService
> # the token disable request arrives on node 1 -> the in-memory storage in
> DefaultTokenStateService will be updated and the DB will also contain
> everything properly. Please note, at this time the token is disabled
> # the token is used on node 2 for authentication purposes -> since the
> in-memory cache already has metadata information about this token, the DB
> will not be checked -> the token is considered enabled
> I did research and found out that we could use PostgreSQL's
> [NOTIFY|https://www.postgresql.org/docs/9.1/sql-notify.html] and
> [LISTEN|https://www.postgresql.org/docs/9.1/sql-listen.html] mechanism to
> implement the observer pattern on our end. Unfortunately, this only works for
> Postgres.
> Instead of going down that way, I'd make the JDBC token state service DB
> vendor-independent by skipping the in-memory lookup for data that can be
> changed:
> * expiration time
> * metadata
> We may have to think about adding connection pooling as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
