[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829044#comment-15829044
]
Andrew Purtell commented on PHOENIX-3607:
-----------------------------------------
We can evict from cache by LRU regardless. Though I see that will be another
JIRA. As it should be.
We get hadoop semantics up through HBase via User because User refers to UGI,
and Phoenix shouldn't change them, and testing User equality by name instead of
subject identity would be such a change. I suggested this in a private
discussion but now believe it to be wrong. Allowing only one cached entry by
user-name can be something Phoenix chooses to do, though won't be necessary if
we expire connections out of the cache by LRU in a reasonably timely manner.
Will avoid leaks that way.
> 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)
