[
https://issues.apache.org/jira/browse/HADOOP-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100931#comment-14100931
]
Sangjin Lee commented on HADOOP-10893:
--------------------------------------
Thanks for the comment, Kihwal.
I agree that if the default is now in the source directly the need to re-define
the same default in mapred-default.xml is less than optimal. I like the idea of
printing out the system classes when the application classloader is
instantiated.
Having said that, how about the definition of the environment variable on the
client classloader usage side (which was added in the latest patch)? To be
symmetric, I think it should be removed again as well.
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)
