[
https://issues.apache.org/jira/browse/HBASE-22415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840613#comment-16840613
]
Sean Mackrory commented on HBASE-22415:
---------------------------------------
Is it possible to change the log level of HBase daemons on the fly? 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. By
which time you've flooded your logs with debug for a long time already without
learning much more yet.
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?
> 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)
