Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Sun, 17 Jun 2012 05:01:44 +0000 (UTC)
From: "Harsh J (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: <921997363.22500.1339909304656.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Resolved] (MAPREDUCE-453) Provide more flexibility in the
 way tasks are run
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Harsh J resolved MAPREDUCE-453.
-------------------------------

    Resolution: Duplicate

HADOOP-3280 and MAPREDUCE-249 covered these ideas already. I am resolving this as a dupe of those alternatives - I do believe the planned feature (minus of the threads-per-task goal) are present in one version or another already today (in different forms).

For threads per task, if that is still a valid gain beyond what MR2's AM does, can be discussed over a new issue.
                
> Provide more flexibility in the way tasks are run
> -------------------------------------------------
>
>                 Key: MAPREDUCE-453
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-453
>             Project: Hadoop Map/Reduce
>          Issue Type: New Feature
>            Reporter: Brice Arnould
>            Assignee: Brice Arnould
>            Priority: Minor
>         Attachments: TaskWrapper_v0.patch, userBasedInsulator.sh
>
>
> *The aim*
> With [HADOOP-3421] speaking about sharing a cluster among more than one organization (so potentially with non-cooperative users), and posts on the ML speaking about virtualization and the ability to re-use the TaskTracker's VM to run new tasks, it could be useful for admins to choose the way TaskRunners run their children. 
> More specifically, it could be useful to provide a way to imprison a Task in its working directory, or in a virtual machine.
> In some cases, reusing the VM might be useful, since it seems that this feature is really wanted ([HADOOP-249]).
> *Concretely*
> What I propose is a new class, called called SeperateVMTaskWrapper which contains the current logic for running tasks in another JVM. This class extends another, called TaskWrapper, which could be inherited to provide new ways of running tasks.
> As part of this issue I would also like to provide two other TaskWrappers : the first would run the tasks as Thread of the TaskRunner's VM (if it is possible without too much changes), the second would use a fixed pool of local unix accounts to insulate tasks from each others (so potentially non-cooperating users will be hable to share a cluster, as described in [HADOOP-3421]).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira