[
https://issues.apache.org/jira/browse/HADOOP-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742749#comment-14742749
]
Sunil G commented on HADOOP-12321:
----------------------------------
Thank you [~steve_l] for aggregating. By seeing jenkins result, compilation
broke for nm,rm,nn,dn,hs as its still expecting JvmPauseMonitor ctor to accept
config. It seems other projects are not considering the changed JvmPauseMonitor.
With same patch in MAPREDUCE-6462, compilation is fine and there are test case
failures. But look like those are not related to this.
> Make JvmPauseMonitor to AbstractService
> ---------------------------------------
>
> Key: HADOOP-12321
> URL: https://issues.apache.org/jira/browse/HADOOP-12321
> Project: Hadoop Common
> Issue Type: New Feature
> Affects Versions: 2.8.0
> Reporter: Steve Loughran
> Assignee: Sunil G
> Attachments: 0001-HADOOP-12321.patch, 0002-HADOOP-12321.patch,
> HADOOP-12321-003.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The new JVM pause monitor has been written with its own start/stop lifecycle
> which has already proven brittle to both ordering of operations and, even
> after HADOOP-12313, is not thread safe (both start and stop are potentially
> re-entrant).
> It also requires every class which supports the monitor to add another field
> and perform the lifecycle operations in its own lifecycle, which, for all
> Yarn services, is the YARN app lifecycle (as implemented in Hadoop common)
> Making the monitor a subclass of {{AbstractService}} and moving the
> init/start & stop operations in {{serviceInit()}}, {{serviceStart()}} &
> {{serviceStop()}} methods will fix the concurrency and state model issues,
> and make it trivial to add as a child to any YARN service which subclasses
> {{CompositeService}} (most the NM and RM apps) will be able to hook up the
> monitor simply by creating one in the ctor and adding it as a child.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
