[jira] [Commented] (HDFS-15215) The Timestamp for longest write/read lock held log is wrong

2020-03-24 Thread Hudson (Jira) 


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

Hudson commented on HDFS-15215:
---

SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #18083 (See 
[https://builds.apache.org/job/Hadoop-trunk-Commit/18083/])
HDFS-15215. The Timestamp for longest write/read lock held log is wrong 
(github: rev d353b30baf6da5b70685cf837cf7095636f345e1)
* (edit) 
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/TestFSNamesystemLock.java
* (edit) 
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/util/FakeTimer.java
* (edit) 
hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystemLock.java


> The Timestamp for longest write/read lock held log is wrong
> ---
>
> Key: HDFS-15215
> URL: https://issues.apache.org/jira/browse/HDFS-15215
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.3.0
>
>
> I found the Timestamp for longest write/read lock held log is wrong in trunk:
> {code}
> 2020-03-10 16:01:26,585 [main] INFO  namenode.FSNamesystem 
> (FSNamesystemLock.java:writeUnlock(281)) - Number of suppressed 
> write-lock reports: 0
>   Longest write-lock held at 1970-01-03 07:07:40,841+0900 for 3ms via 
> java.lang.Thread.getStackTrace(Thread.java:1559)
> ...
> {code}
> Looking at the code, it looks like the timestamp comes from System.nanoTime() 
> that returns the current value of the running Java Virtual Machine's 
> high-resolution time source and this method can only be used to measure 
> elapsed time:
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--
> We need to make the timestamp from System.currentTimeMillis().



--
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

[jira] [Commented] (HDFS-15215) The Timestamp for longest write/read lock held log is wrong

2020-03-24 Thread Jira 


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

Íñigo Goiri commented on HDFS-15215:


Thanks [~brfrn169] for the fix.
Merged the PR to trunk.

> The Timestamp for longest write/read lock held log is wrong
> ---
>
> Key: HDFS-15215
> URL: https://issues.apache.org/jira/browse/HDFS-15215
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.3.0
>
>
> I found the Timestamp for longest write/read lock held log is wrong in trunk:
> {code}
> 2020-03-10 16:01:26,585 [main] INFO  namenode.FSNamesystem 
> (FSNamesystemLock.java:writeUnlock(281)) - Number of suppressed 
> write-lock reports: 0
>   Longest write-lock held at 1970-01-03 07:07:40,841+0900 for 3ms via 
> java.lang.Thread.getStackTrace(Thread.java:1559)
> ...
> {code}
> Looking at the code, it looks like the timestamp comes from System.nanoTime() 
> that returns the current value of the running Java Virtual Machine's 
> high-resolution time source and this method can only be used to measure 
> elapsed time:
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--
> We need to make the timestamp from System.currentTimeMillis().



--
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

[jira] [Commented] (HDFS-15215) The Timestamp for longest write/read lock held log is wrong

2020-03-10 Thread Toshihiro Suzuki (Jira) 


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

Toshihiro Suzuki commented on HDFS-15215:
-

[~elgoiri] Thank you for reviewing this. I just force-pushed a new commit which 
modified the existing test to verify the fix.

> The Timestamp for longest write/read lock held log is wrong
> ---
>
> Key: HDFS-15215
> URL: https://issues.apache.org/jira/browse/HDFS-15215
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
>
> I found the Timestamp for longest write/read lock held log is wrong in trunk:
> {code}
> 2020-03-10 16:01:26,585 [main] INFO  namenode.FSNamesystem 
> (FSNamesystemLock.java:writeUnlock(281)) - Number of suppressed 
> write-lock reports: 0
>   Longest write-lock held at 1970-01-03 07:07:40,841+0900 for 3ms via 
> java.lang.Thread.getStackTrace(Thread.java:1559)
> ...
> {code}
> Looking at the code, it looks like the timestamp comes from System.nanoTime() 
> that returns the current value of the running Java Virtual Machine's 
> high-resolution time source and this method can only be used to measure 
> elapsed time:
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--
> We need to make the timestamp from System.currentTimeMillis().



--
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

[jira] [Commented] (HDFS-15215) The Timestamp for longest write/read lock held log is wrong

2020-03-10 Thread Jira 


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

Íñigo Goiri commented on HDFS-15215:


Can we add a test that checks that the date is around the current time?

> The Timestamp for longest write/read lock held log is wrong
> ---
>
> Key: HDFS-15215
> URL: https://issues.apache.org/jira/browse/HDFS-15215
> Project: Hadoop HDFS
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
>
> I found the Timestamp for longest write/read lock held log is wrong in trunk:
> {code}
> 2020-03-10 16:01:26,585 [main] INFO  namenode.FSNamesystem 
> (FSNamesystemLock.java:writeUnlock(281)) - Number of suppressed 
> write-lock reports: 0
>   Longest write-lock held at 1970-01-03 07:07:40,841+0900 for 3ms via 
> java.lang.Thread.getStackTrace(Thread.java:1559)
> ...
> {code}
> Looking at the code, it looks like the timestamp comes from System.nanoTime() 
> that returns the current value of the running Java Virtual Machine's 
> high-resolution time source and this method can only be used to measure 
> elapsed time:
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--
> We need to make the timestamp from System.currentTimeMillis().



--
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