[ 
https://issues.apache.org/jira/browse/HADOOP-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021638#comment-15021638
 ] 

Hadoop QA commented on HADOOP-12321:
------------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s {color} 
| {color:red} HADOOP-12321 does not apply to trunk. Rebase required? Wrong 
Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HADOOP-12321 |
| GITHUB PR | https://github.com/apache/hadoop/pull/54 |
| Powered by | Apache Yetus   http://yetus.apache.org |
| Console output | 
https://builds.apache.org/job/PreCommit-HADOOP-Build/8135/console |
| Console output | 
https://builds.apache.org/job/PreCommit-HADOOP-Build/8135/console |


This message was automatically generated.



> 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, 
> 0004-HADOOP-12321.patch, HADOOP-12321-003.patch, 
> HADOOP-12321-005-aggregated.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)

Reply via email to