You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2017/01/10 17:45:58 UTC

[jira] [Commented] (PHOENIX-3584) Expose metrics for ConnectionQueryServices instances and their allocators in the JVM

    [ https://issues.apache.org/jira/browse/PHOENIX-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815634#comment-15815634 ] 

James Taylor commented on PHOENIX-3584:
---------------------------------------

[~samarthjain] - we're seeing many zookeeper connections and need to rule out Phoenix as the culprit. Do you think you could put together a patch to capture this global metric?

> 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
>
> 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)