[
https://issues.apache.org/jira/browse/HADOOP-12855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15184747#comment-15184747
]
Steve Loughran commented on HADOOP-12855:
-----------------------------------------
OK, so now the situation is
-the first JvmMonitor instance starts the monitor thread
-the last instance stops it.
This is going to be complicated enough to need a test. If some flag could let
callers know if the monitor thread was running, then a unit test coudl start
two instances, stop the first one, verify that the thread was running, stop the
second, verify it was now stopped
also set monitorThread==null in the stop operation.
> Add option to disable JVMPauseMonitor across services
> -----------------------------------------------------
>
> Key: HADOOP-12855
> URL: https://issues.apache.org/jira/browse/HADOOP-12855
> Project: Hadoop Common
> Issue Type: Improvement
> Components: performance, test
> Affects Versions: 2.8.0
> Environment: JVMs with miniHDFS and miniYarn clusters
> Reporter: Steve Loughran
> Assignee: John Zhuge
> Attachments: HADOOP-12855-001.patch, HADOOP-12855-002.patch,
> HADOOP-12855-003.patch
>
>
> Now that the YARN and HDFS services automatically start a JVM pause monitor,
> if you start up the mini HDFS and YARN clusters, with history server, you are
> spinning off 5 + threads, all looking for JVM pauses, all printing things out
> when it happens.
> We do not need these monitors in minicluster testing; they merely add load
> and noise to tests.
> Rather than retrofit new options everywhere, how about having a
> "jvm.pause.monitor.enabled" flag (default true), which, when set, starts off
> the monitor thread.
> That way, the existing code is unchanged, there is always a JVM pause monitor
> for the various services —it just isn't spinning up threads.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
