[ 
https://issues.apache.org/jira/browse/HDFS-14775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958486#comment-16958486
 ] 

Chen Zhang commented on HDFS-14775:
-----------------------------------

Hi [~hexiaoqiao] and [~elgoiri] ,Thanks for your comments, sorry for the late 
response.
{quote}I guess that you remote AtomicReference for `longestWriteLockHeldInfo` 
based on only one thread could hold WriteLock, right? maybe we could keep 
AtomicReference safety and it will not take any performance overhead in my 
opinion
{quote}
Yep, this critical section is already protected by the write lock, so we don't 
need to consider any race condition, which will simplify the code.
{quote}const in FSNamesystemLock#hashCode is just a little confused. is it 
better with {{Objects.hashCode}}?
{quote}
For the {{hashCode}} and {{equals}} method, I think [~hexiaoqiao] is right, we 
can just use the default implementation, since we need neither to compare by 
value nor to save it in some container. What's your opinion? [~elgoiri]
{quote}I wonder if by moving from ReadLockHeldInfo to LockHeldInfo we are 
losing some of the semantic here.
{quote}
I think it's ok, because ReadLockHeldInfo is not designed specifically for 
ReadLock, it just save some general information to track when and where we hold 
a lock.

> Add Timestamp for longest FSN write/read lock held log
> ------------------------------------------------------
>
>                 Key: HDFS-14775
>                 URL: https://issues.apache.org/jira/browse/HDFS-14775
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Chen Zhang
>            Assignee: Chen Zhang
>            Priority: Major
>         Attachments: HDFS-14775.001.patch, HDFS-14775.002.patch, 
> HDFS-14775.003.patch
>
>
> HDFS-13946 improved the log for longest read/write lock held time, it's very 
> useful improvement.
> In some condition, we need to locate the detailed call information(user, ip, 
> path, etc.) for longest lock holder, but the default throttle interval(10s) 
> is too long to find the corresponding audit log. I think we should add the 
> timestamp for the {{longestWriteLockHeldStackTrace}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to