[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828684#comment-15828684
]
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 leaks.
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.
[~apurtell]
> 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)
