[
https://issues.apache.org/jira/browse/PHOENIX-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815942#comment-15815942
]
Andrew Purtell edited comment on PHOENIX-3584 at 1/10/17 7:33 PM:
------------------------------------------------------------------
I think we need to track allocators by hash of stacktrace because a client
supplies that optional connect string parameter, and could arbitrarily vary it,
perhaps generating a unique value per connection, so counting there wouldn't
work right.
was (Author: apurtell):
Personally I think we need to track allocators by hash of stacktrace because a
client supplies that optional connect string parameter, and could arbitrarily
vary it, perhaps generating a unique value per connection, so counting there
wouldn't work right.
> 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)
