[
https://issues.apache.org/jira/browse/HDFS-10817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15450738#comment-15450738
]
Erik Krogen commented on HDFS-10817:
------------------------------------
Thanks for the comments [~zhz]! Uploading a new patch addressing some comments
as described below.
1. Thanks for pointing that out. Updated.
2. Done. I originally had it that way because I didn't want to grab the
ThreadLocal while inside the lock but after further considering the performance
characteristics of this I do not think it is an issue.
3. It is my understanding that it is good practice to clean up ThreadLocal
values when you are finished with them, especially if they are set within a
thread pool (which, IIUC, they are here). See
http://stackoverflow.com/a/818120/5594176. However I do not have much
experience with ThreadLocals and will defer to your call.
4. I have made those a little more robust.
5. This actually isn't possible under the current {{FSNamesystemLock}} design.
Within {{FSNamesystemLock}}, the methods to actually lock are not exposed. It
simply has methods {{writeLock}} and {{readLock}} which return the respective
lock, then the calling class uses the {{lock}}/{{lockIinterruptibly}} methods
on the returned objects.
6. This is a good idea. I have added more variety to the threads which are
tested in {{testFSReadLockLongHoldingReport}}.
> 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
> Attachments: HDFS-10817.000.patch, HDFS-10817.001.patch,
> HDFS-10817.002.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]
