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