phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3607) Change hashCode calculation for caching ConnectionQueryServicesImpls
Date Wed, 18 Jan 2017 20:32:26 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828733#comment-15828733
] 

Josh Elser commented on PHOENIX-3607:
-------------------------------------

Thanks, Geoffrey. This is super helpful.

bq. 1. Client requests a secure connection. The PhoenixEmbeddedDriver code logs them in, creates
a ConnectionInfo, and caches, then returns the connection to the client.

Can you be more specific here? Does this mean that you're using the automatic Kerberos login
via the JDBC url properties? If so, PHOENIX-3232 is relevant.

I'm still trying to re-wrap my head around the problem. I'm thinking that it's related to
the final User field on the ConnectionInfo. I really don't think that Phoenix is managing
these credentials correctly. PHOENIX-3126 was the original case which outlined this. Maybe
ConnectionInfo's should only use the user-name to references the ConnectionQueryServices object,
but this doesn't do anything to prevent the {{UGI.getCurrentUser()}} from not matching what
is specified in the ConnectionInfo.

Along these lines, a comment I left to try to explain this.

{noformat}
                    // PHOENIX-3189 Because ConnectionInfo is immutable, we must make sure
all parts of it are correct before
                    // construction; this also requires the Kerberos user credentials object
(since they are compared by reference
                    // and not by value. If the user provided a principal and keytab via the
JDBC url, we must make sure that the
                    // Kerberos login happens *before* we construct the ConnectionInfo object.
Otherwise, the use of ConnectionInfo
                    // to determine when ConnectionQueryServices impl's should be reused will
be broken.
{noformat}

bq.  2. Under a separate JIRA, we'd like to make the ConnectionInfo/CQSI cache gradually expire
entries in LRU fashion. 

This sounds like a good idea. Hopefully, we can do this in a way that doesn't cause clients
to do anything special when the elements are evicted.

Finally, sorry for leaving this mess in a bad state -- LMK how I can help.

> Change hashCode calculation for caching ConnectionQueryServicesImpls
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-3607
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3607
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.8.0, 4.9.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>
> PhoenixDriver maintains a cache of ConnectionInfo -> ConnectionQueryServicesImpl (each
of which holds a single HConnection) : 
> The hash code of ConnectionInfo in part uses the hash code of its HBase User object,
which uses the *identity hash* of the Subject allocated at login. There are concerns about
the stability of this hashcode. When we log out and log in after TGT refresh, will we have
a new Subject?
> To be defensive, we should do a hash of the string returned by user.getName() instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message