[
https://issues.apache.org/jira/browse/KNOX-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17412407#comment-17412407
]
ASF subversion and git services commented on KNOX-2658:
-------------------------------------------------------
Commit 486abb0c3ad1d9ad6d3deb1af2dbe73da1968970 in knox's branch
refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=486abb0 ]
KNOX-2658 - Skipping in-memory lookup while fetching expiration/metadata for a
token (#490)
> 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)
