[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828822#comment-15828822
]
Geoffrey Jacoby commented on PHOENIX-3607:
------------------------------------------
So then I think it comes down to a simple question: what should happen to the
cache if a ConnectionInfo with a new-but-semantically-identical User comes
along?
If the correct answer is "We shouldn't reuse the existing cached CQSI because
ConnectionInfos are immutable and the new User should make it count as a
different ConnectionInfo", then we should create a new CQSI, but the code
should synchronously make sure that any semantically-identical ConnectionInfos
are explicitly expired out of the cache at that time so we don't leak.
On the other hand, if the correct answer is "We should reuse the existing
cached CQSI", then we should change the hashCode as proposed in this JIRA, so
that the new ConnectionInfo hashes to the same value as the old one.
Or, to put it another way: should we use object or semantic equality for
ConnectionInfo objects?
Either way, I think we should go forward with the LRU expiration of the cache.
> 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)
