[
https://issues.apache.org/jira/browse/KNOX-2658?focusedWorklogId=648436&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-648436
]
ASF GitHub Bot logged work on KNOX-2658:
----------------------------------------
Author: ASF GitHub Bot
Created on: 09/Sep/21 07:33
Start Date: 09/Sep/21 07:33
Worklog Time Spent: 10m
Work Description: smolnar82 commented on pull request #490:
URL: https://github.com/apache/knox/pull/490#issuecomment-915837967
> > 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.
>
> I see, I am cool with it knowing this has been discussed and will be
addressed in the future patches :)
> Thanks!
https://issues.apache.org/jira/browse/KNOX-2660
--
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: 648436)
Time Spent: 1h (was: 50m)
> 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: 1h
> 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)
