[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828655#comment-15828655
]
Josh Elser commented on PHOENIX-3607:
-------------------------------------
I think there were issues WRT proxy-user authentication in this case. When the
end-user was riding on top of some other user's credentials (I think this was
ultimately stemming from an Apache Zeppelin use-case), it was leaking
connections.
I also remember the convenience JDBC URL principal+keytab properties being
problematic.
Is there a concrete case that you can share, [~gjacoby]? It would be good to
have something firm that we can show does/does-not work, and then work from
there. In general, this is rather difficult to do correctly due to the caching
that PhoenixDriver tries to do. The inversion of control WRT the
{{Subject.doAs}} calls makes it tough for Phoenix to encapsulate this while
supporting multiple users in the same JVM.
> 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)
