[
https://issues.apache.org/jira/browse/HDFS-10817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468261#comment-15468261
]
Arpit Agarwal commented on HDFS-10817:
--------------------------------------
Hi [~xkrogen],
Thanks for adding this instrumentation. IIUC this implicitly assumes that with
multiple readers, first thread to acquire the read lock will be the last thread
to release it, since only the first thread to get the read lock will update
readLockHeldTimeStamp. If another thread is the last to release it then
{{readLockHeldTimeStamp.get()}} is going to return LONG.MAX_VALUE so the
calculation will be off.
> Add Logging for Long-held NN Read Locks
> ---------------------------------------
>
> Key: HDFS-10817
> URL: https://issues.apache.org/jira/browse/HDFS-10817
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: logging, namenode
> Reporter: Erik Krogen
> Assignee: Erik Krogen
> Fix For: 2.8.0, 2.7.4, 3.0.0-alpha2
>
> Attachments: HDFS-10817.000.patch, HDFS-10817.001.patch,
> HDFS-10817.002.patch, HDFS-10817.003.patch, HDFS-10817.004.patch,
> HDFS-10817.addendum.000.patch, HDFS-10817.addendum.001.patch
>
>
> Right now the Namenode will log when a write lock is held for a long time to
> help tracks methods which are causing expensive delays. Let's do the same for
> read locks since these operations may also be expensive/long and cause
> delays.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
