[
https://issues.apache.org/jira/browse/HBASE-22415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841487#comment-16841487
]
Wellington Chevreuil commented on HBASE-22415:
----------------------------------------------
{quote}Is it possible to change the log level of HBase daemons on the fly?
{quote}
Yes, this is possible. HBase UI's have logLevel page for changing it, just like
in HDFS UIs.
{quote} If someone starts hitting a scenario where a lock has been held for a
very long time, I'd want to make sure they can find it easily without
restarting their whole cluster and possibly resetting a deadlock that will come
back a week later.
{quote}
That's a valid concern, but as answered above, we can then switch log level to
DEBUG for hboss package only without needing a restart.
{quote}I wonder if a better approach is to pull back on the retry logic a
little bit - we could probably increase the lock retry period by an order of
magnitude or two, with a corresponding decrease in noise, without impacting
practical performance much. Thoughts?
{quote}
I would rather keep it as simple as it is now. My view here might be biased,
but I believe the ability to switch on debug level at runtime, plus some RSes
jstacks would suffice to troubleshoot/identify hboss related locks issues, like
the discussed on [pull request
here|https://github.com/apache/hbase-filesystem/pull/1#pullrequestreview-233501571],
fixed by HBASE-22386.
Still on the "supportability" subject, we may think about defining some JMX
metrics for tracking possible lock contentions?
> HBOSS: Reduce log verbosity in ZKTreeLockManager when waiting on a
> parent/child node lock
> -----------------------------------------------------------------------------------------
>
> Key: HBASE-22415
> URL: https://issues.apache.org/jira/browse/HBASE-22415
> Project: HBase
> Issue Type: Improvement
> Reporter: Wellington Chevreuil
> Assignee: Wellington Chevreuil
> Priority: Minor
> Labels: HBOSS
> Attachments: HBASE-22415.master.001.patch
>
>
> On normal read/write workloads, it will be very often that requests will
> reach an temporary "locked" node by some other requests, causing process logs
> to flood with the messages been currently logged as WARN. To improve
> supportability, am proposing a patch that reduces these logging to DEBUG.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
