[
https://issues.apache.org/jira/browse/HDFS-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Krogen updated HDFS-11290:
-------------------------------
Attachment: HDFS-11290.000.patch
Attaching a patch which uses a {{Thread.sleep(1000)}} to force the JMX cache to
expire. The way the metrics system is currently set up you can't set a JMX
cache TTL below 1 second; setting the period to 0 causes an
{{IllegalArgumentException}} in {{MetricsSystemImpl#startTimer()}}... Open to
suggestions on a better way to do this, but it's a little tricky since it's an
integration-style test so I can't easily hook into/modify the metrics system. I
verified that without this patch it's possible for {{testWithFSEditLogLock}} to
pass (as well as {{testWithFSNamesystemWriteLock}} if I increase the JMX cache
TTL to 20 seconds, so it's basically performance-dependent) if I change
{{FSNamesystem#getLastWrittenTransactionId}} to the following, which should
cause both to fail:
{code}
public long getLastWrittenTransactionId() {
readLock();
readUnlock();
return getEditLog().getLastWrittenTxId();
}
{code}
[~ajisakaa], any thoughts?
> TestFSNameSystemMBean should wait until the cache is cleared
> ------------------------------------------------------------
>
> Key: HDFS-11290
> URL: https://issues.apache.org/jira/browse/HDFS-11290
> Project: Hadoop HDFS
> Issue Type: Test
> Components: test
> Affects Versions: 2.8.0
> Reporter: Akira Ajisaka
> Assignee: Erik Krogen
> Attachments: HDFS-11290.000.patch
>
>
> TestFSNamesystemMBean#testWithFSNamesystemWriteLock and
> #testWithFSEditLogLock get metrics after locking FSNameSystem/FSEditLog, but
> when the metrics are cached, the tests success even if the metrics acquire
> the locks. The tests should wait until the cache is cleared.
> This issue was reported by [~xkrogen] in HDFS-11180.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
