[
https://issues.apache.org/jira/browse/PHOENIX-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15816963#comment-15816963
]
Hudson commented on PHOENIX-3584:
---------------------------------
SUCCESS: Integrated in Jenkins build Phoenix-master #1532 (See
[https://builds.apache.org/job/Phoenix-master/1532/])
PHOENIX-3584 Expose metrics for ConnectionQueryServices instances and (samarth:
rev f5de28b6d79141c555c994a94af7b4078872d845)
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/monitoring/GlobalClientMetrics.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/monitoring/MetricType.java
* (edit)
phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
> 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)
