hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Krogen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10817) Add Logging for Long-held NN Read Locks
Date Wed, 31 Aug 2016 01:47:22 GMT

    [ 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

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

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message