[jira] [Resolved] (KNOX-2658) JDBCTokenStateService is not HA-compatible

["Sandor Molnar (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KNOX-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sandor Molnar resolved KNOX-2658.
---------------------------------
    Fix Version/s: 1.6.0
       Resolution: Fixed

> 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
>             Fix For: 1.6.0
>
>          Time Spent: 1h 10m
>  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)