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

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

Sandor Molnar created KNOX-2658:
-----------------------------------

             Summary: 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


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)