phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3607) Change hashCode calculation for caching ConnectionQueryServicesImpls
Date Tue, 24 Jan 2017 23:31:26 GMT


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:
>             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

View raw message