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 Wed, 18 Jan 2017 20:01:26 GMT


Geoffrey Jacoby commented on PHOENIX-3607:

[~elserj] We're seeing Phoenix connections leak over time in secure clusters. One use case
we're concerned about is:

1. Client requests a secure connection. The PhoenixEmbeddedDriver code logs them in, creates
a ConnectionInfo, and caches, then returns the connection to the client.

2. Sometime later, the client requests a secure connection again with the same credentials.
ConnectionInfo#normalize realizes that the kerberos ticket has expired, and re-logs in with
a different User object and different Subject, but semantically equal to the ConnectionInfo
in step 1. 

3. It tries to look up a cached ConnectionQueryServicesImpl/HConnection in the cache, but
it misses because the hash codes of the two ConnectionInfos are different. A new ConnectionQueryServicesImpl
and HConnection are created, and put in the cache. 

4. The old cache entry from step 1 will never be used or purged, and so its CQSI and HConnection

The two changes we're proposing as fixes are:
1. Change the hashing function of ConnectionInfo so that semantically identical instances
will return the same hash code even if their User subjects are different instances (e.g. use
User.getUserName() instead of User in ConnectionInfo.hashCode()) 
2. Under a separate JIRA, we'd like to make the ConnectionInfo/CQSI cache gradually expire
entries in LRU fashion. 


> 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