[ 
https://issues.apache.org/jira/browse/KNOX-2658?focusedWorklogId=647374&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-647374
 ]

ASF GitHub Bot logged work on KNOX-2658:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 07/Sep/21 13:43
            Start Date: 07/Sep/21 13:43
    Worklog Time Spent: 10m 
      Work Description: smolnar82 opened a new pull request #490:
URL: https://github.com/apache/knox/pull/490


   ## What changes were proposed in this pull request?
   
   As described in the JIRA; in-memory lookup is skipped in JDBC token state 
service while fetching token expiration or metadata. Instead, we go directly to 
the DB in this implementation.
   Since those queries are simple (there is no table join involved) and they 
rely on indexed columns the is no significant performance issue.
   
   ## How was this patch tested?
   
   Updated JUnit test cases and repeated the same steps as described in the 
JIRA. With my fix, the disabled authentication request fails on node 2 like 
this:
   ```
   $ curl -ku 
Passcode:WXpVNVlUZGlNRGt0WWpFMk5TMDBZamxsTFRobVpEY3ROV0psWW1WbE1EVTRZakF4OjpOVFptWW1VNVlXVXROelppTVMwME5URmhMVGcxWXpRdFl6Z3hNVEUwTmpkak5XUTA=
 https://localhost:8444/gateway/tokenbased/webhdfs/v1?op=LISTSTATUS
   <html>
   <head>
   <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
   <title>Error 401 Token c59a7b09...5bebee058b01 is disabled</title>
   </head>
   <body><h2>HTTP ERROR 401 Token c59a7b09...5bebee058b01 is disabled</h2>
   <table>
   <tr><th>URI:</th><td>/gateway/tokenbased/webhdfs/v1</td></tr>
   <tr><th>STATUS:</th><td>401</td></tr>
   <tr><th>MESSAGE:</th><td>Token c59a7b09...5bebee058b01 is disabled</td></tr>
   <tr><th>SERVLET:</th><td>tokenbased-knox-gateway-servlet</td></tr>
   </table>
   
   </body>
   </html>
   ```


-- 
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: 647374)
    Remaining Estimate: 0h
            Time Spent: 10m

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

Reply via email to