[jira] [Commented] (HADOOP-12321) Make JvmPauseMonitor to AbstractService

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on HADOOP-12321:
-----------------------------------------

GitHub user steveloughran opened a pull request:

    https://github.com/apache/hadoop/pull/54

    HADOOP-12321

    This is HADOOP-12321-005-aggregated applied as is to trunk;

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/steveloughran/hadoop incoming/HADOOP-12321-jvm-aggregated

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/hadoop/pull/54.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #54
    
----
commit 15465e590b256b4dec43298304b9196f34027f00
Author: Steve Loughran <st...@hortonworks.com>
Date:   2015-11-22T18:42:42Z

    apply HADOOP-12321-005-aggregated locally

----


> 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)