Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 15 Jan 2016 21:06:39 +0000 (UTC)
From: "Xuan Gong (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12929237.1452533742000.125929.1452891999978@Atlassian.JIRA>
In-Reply-To: <JIRA.12929237.1452533742000@Atlassian.JIRA>
References: <JIRA.12929237.1452533742000@Atlassian.JIRA>
 <JIRA.12929237.1452533742513@arcas>
Subject: [jira] [Updated] (YARN-4577) Enable aux services to have their own
 custom classpath/jar file
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/YARN-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xuan Gong updated YARN-4577:
----------------------------
    Attachment: YARN-4577.3.patch

> Enable aux services to have their own custom classpath/jar file
> ---------------------------------------------------------------
>
>                 Key: YARN-4577
>                 URL: https://issues.apache.org/jira/browse/YARN-4577
>             Project: Hadoop YARN
>          Issue Type: Improvement
>    Affects Versions: 2.8.0
>            Reporter: Xuan Gong
>            Assignee: Xuan Gong
>         Attachments: YARN-4577.1.patch, YARN-4577.2.patch, YARN-4577.3.patch
>
>
> Right now, users have to add their jars to the NM classpath directly, thus put them on the system classloader. But if multiple versions of the plugin are present on the classpath, there is no control over which version actually gets loaded. Or if there are any conflicts between the dependencies introduced by the auxiliary service and the NM itself, they can break the NM, the auxiliary service, or both.
> The solution could be: to instantiate aux services using a classloader that is different from the system classloader.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)