[
https://issues.apache.org/jira/browse/MAPREDUCE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786859#action_12786859
]
Vinod K V commented on MAPREDUCE-967:
-------------------------------------
Overall, the patch looked good to me too.
One point of concern, similar to what I had on HADOOP-6346, is the
{{classpath}}: paths unjarred are not put on the classpath. Granted, files
unjarred like this are usable for direct access(like the -file case of
streaming). Even if one gives a user specified directory to be unjarred, I
don't see a way he/she can use it to find classes. Write a custom
{{ClassLoader}}? In that case, does he/she even need to unjar it? Any idea?
Another point: the changes to classpath in {{TaskRunner}} seem suspicious.
Earlier, we had
{code}
classPaths.add(jobCacheDir.toString());
{code}
and now only
{code}
classPaths.add(new File(jobCacheDir, "job.jar").toString());
{code}
Is this intentional? May be we need both? Throw some light?
> TaskTracker does not need to fully unjar job jars
> -------------------------------------------------
>
> Key: MAPREDUCE-967
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-967
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: tasktracker
> Affects Versions: 0.21.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Attachments: mapreduce-967-branch-0.20.txt, mapreduce-967.txt,
> mapreduce-967.txt, mapreduce-967.txt
>
>
> In practice we have seen some users submitting job jars that consist of
> 10,000+ classes. Unpacking these jars into mapred.local.dir and then cleaning
> up after them has a significant cost (both in wall clock and in unnecessary
> heavy disk utilization). This cost can be easily avoided
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
