One concern is that do we need to dump the longest lock interval information during the suppressed interval, including lock-holding interval and its thread stack. This should reveal more useful information. One extreme example is a case where two threads (t1 and t2) holding the write lock in a sequence: t1-1s, t2-100s, t1-1s, in the current implementation the t2 information will be missing though it's more interesting.
414 415 public static final String DFS_LOCK_SUPPRESS_WARNING_INTERVAL_MS_KEY =
417 public static final long DFS_LOCK_SUPPRESS_WARNING_INTERVAL_MS_DEFAULT =
2629 <description>The interval between reporting lock warnings.
I believe the default value of config key dfs.lock.suppress.warning.interval.ms is 2 mins not 1 second?
- In line 1571, message "Number of suppressed write-lock reports: " + numSuppressedWarnings); should have a "\n" or "\t" before it.
- Let's make private final long writeLockReportingThreshold; and private final long writeLockSuppressWarningInterval; final.
As the following work, Jing Zhao also suggest we have a look at the feasibility to expose this information to nntop metrics.