[
https://issues.apache.org/jira/browse/HDFS-10713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504738#comment-15504738
]
Chris Douglas commented on HDFS-10713:
--------------------------------------
+0 on v11. Since HDFS-10817 and related JIRAs are adding some overhead to a
critical section of the NN (literally), has anybody measured throughput/latency
differences when compared to branch-2?
* Minor:
{noformat}
+ do {
+ localLongestReadLock = longestReadLockHeldInterval.get();
+ if (readLockInterval < localLongestReadLock) {
+ break;
+ }
+ } while (!longestReadLockHeldInterval.compareAndSet(
+ localLongestReadLock, readLockInterval));
{noformat}
Equivalently
{code}
do {
localLongestReadLock = longestReadLockHeldInterval.get();
} while (localLongestReadLock - readLockInterval < 0
&& !longestReadLockHeldInterval.compareAndSet(localLongestReadLock,
readLockInterval));
{code}
Following
[guidance|https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#nanoTime--]
on {{System#nanoTime}} and avoiding redundant assignment when
{{readLockInterval == localLongestReadLock}}.
* Are the {{\@VisibleForTesting}} methods {{setTimeStampOfLastReadLockReport}}
and {{setTimeStampOfLastWriteLockReport}} necessary for the unit test?
* Missing replacement call to {{FakeTimer#advance}}:
{noformat}
fsn.writeLock();
- Thread.sleep(writeLockReportingThreshold / 2);
fsn.writeUnlock();
{noformat}
> Throttle FsNameSystem lock warnings
> -----------------------------------
>
> Key: HDFS-10713
> URL: https://issues.apache.org/jira/browse/HDFS-10713
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: logging, namenode
> Reporter: Arpit Agarwal
> Assignee: Hanisha Koneru
> Attachments: HDFS-10713.000.patch, HDFS-10713.001.patch,
> HDFS-10713.002.patch, HDFS-10713.003.patch, HDFS-10713.004.patch,
> HDFS-10713.005.patch, HDFS-10713.006.patch, HDFS-10713.007.patch,
> HDFS-10713.008.patch, HDFS-10713.009.patch, HDFS-10713.010.patch,
> HDFS-10713.011.patch
>
>
> The NameNode logs a message if the FSNamesystem write lock is held by a
> thread for over 1 second. These messages can be throttled to at one most one
> per x minutes to avoid potentially filling up NN logs. We can also log the
> number of suppressed notices since the last log message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
