[ https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836843#comment-15836843 ]
Geoffrey Jacoby commented on PHOENIX-3607: ------------------------------------------ Looking back over the previous JIRAs (both in Phoenix and Hadoop), it appears that taking User out of the hashCode would just lead to the problem that PHOENIX-3126 fixed, and that User's strange Subject instance-based hashing is done for a valid reason given the quirks of Hadoop authentication. That means that we shouldn't reuse the same ConnectionQueryServices after a change in authentication, and should keep the hashing function the same to protect from users getting HConnections with the wrong authentication. Above I suggested explicitly expiring and closing orphaned ConnectionInfo/CQSI pairs, but PHOENIX-3611 accomplishes much the same thing in a more general way by having max size and max age LRU policies in the connection cache. The more I think of it, that seems sufficient. Is there general agreement on this -- in which case I'll either Won't Fix or Not a Problem this JIRA -- or is there more that needs to be done here? > 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)