[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838291#comment-15838291
]
Andrew Purtell commented on PHOENIX-3607:
-----------------------------------------
Agreed, we'd only want to release/close a connection relatively recent after
creation if we know it has somehow been "released" by the client. I do think
LRU expiry is fine if the interval is reasonably large. Agreed the scenario of
a leaked connection in that case is more likely than others.
Not sure we want to cache weak references. What I like about the approach
[~gjacoby] used is Guava's Cache has a removal listener that takes action then.
If we wait to close connections in finalize() then we can significantly stall
GC. I've seen that happen when actions out of a finalizer do something locally
with file IO. Longer waits for IO over a busy network might be even worse.
> 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)
