[
https://issues.apache.org/jira/browse/PHOENIX-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samarth Jain resolved PHOENIX-3584.
-----------------------------------
Resolution: Fixed
Fix Version/s: 4.10.0
4.9.1
> Expose metrics for ConnectionQueryServices instances and their allocators in
> the JVM
> ------------------------------------------------------------------------------------
>
> Key: PHOENIX-3584
> URL: https://issues.apache.org/jira/browse/PHOENIX-3584
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: Samarth Jain
> Fix For: 4.9.1, 4.10.0
>
> Attachments: PHOENIX-3584.patch
>
>
> In the case a client is leaking Phoenix/HBase connections it would be helpful
> to have metrics available on the number of ConnectionQueryServices
> (ConnectionQueryServicesImpl) instances and who has allocated them.
> For the latter, we could get a stacktrace when ConnectionQueryServicesImpls
> are allocated (should be a relatively rare) and keep a count by hash of the
> call stack (and save the call stack). Then we need a method to dump the hash
> to callstack map as a string. This method can be called remotely by JMX when
> debugging leaks in a live environment. Perhaps after the count of
> ConnectionQueryServicesImpls goes over a configurable threshold we can also
> log warnings that dump the counts by hash and callstacks corresponding to
> those hashes.
> Or, we should only have multiple ConnectionQueryServicesImpls if an optional
> parameter is passed in the JDBC connect string. We could keep counts by that
> parameter string and dump that instead of call stacks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
