[
https://issues.apache.org/jira/browse/HADOOP-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100729#comment-14100729
]
Kihwal Lee commented on HADOOP-10893:
-------------------------------------
The latest patch looks good. One thing I am not sure about is leaving the conf
in mapred-default.xml. Since the default system classes are in the code, the
entry in mapred-site.xml kind of serves as documentation, which needs to be
kept in sync with the code. From pure functionality point of view, we can
simply remove them, but then those who want to modify the list need to look at
the code? Maybe we can have MR logs show list of system classes when the app
class loader is activated. Then it might be easier for users to figure out the
default/current list and modify. Any other thoughts?
> isolated classloader on the client side
> ---------------------------------------
>
> Key: HADOOP-10893
> URL: https://issues.apache.org/jira/browse/HADOOP-10893
> Project: Hadoop Common
> Issue Type: New Feature
> Components: util
> Affects Versions: 2.4.0
> Reporter: Sangjin Lee
> Assignee: Sangjin Lee
> Attachments: HADOOP-10893.patch, HADOOP-10893.patch,
> HADOOP-10893.patch, HADOOP-10893.patch, classloader-test.tar.gz
>
>
> We have the job classloader on the mapreduce tasks that run on the cluster.
> It has a benefit of being able to isolate class space for user code and avoid
> version clashes.
> Although it occurs less often, version clashes do occur on the client JVM. It
> would be good to introduce an isolated classloader on the client side as well
> to address this. A natural point to introduce this may be through RunJar, as
> that's how most of hadoop jobs are run.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
