Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Message-ID: <32378118.239531281380423712.JavaMail.jira@thor>
Date: Mon, 9 Aug 2010 15:00:23 -0400 (EDT)
From: "Luke Lu (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Subject: [jira] Commented: (MAPREDUCE-1881) Improve
 TaskTrackerInstrumentation
In-Reply-To: <20831650.97611277001383337.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MAPREDUCE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896663#action_12896663 ] 

Luke Lu commented on MAPREDUCE-1881:
------------------------------------

Having to be routed via the default composite object is really what I object. There are many reasons why it's a bad idea. However there is a simple fix to your patch: if there is only one class specified in the config, use it as the top level class instead of a delegate in the default composite class. This way, user (arguably expert :), who want to mess with tasktracker implementation) convenience is preserved and the default composite class implementation is overridable.

> Improve TaskTrackerInstrumentation
> ----------------------------------
>
>                 Key: MAPREDUCE-1881
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-1881
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>            Reporter: Matei Zaharia
>            Assignee: Matei Zaharia
>            Priority: Minor
>         Attachments: mapreduce-1881-v2.patch, mapreduce-1881.patch
>
>
> The TaskTrackerInstrumentation class provides a useful way to capture key events at the TaskTracker for use in various reporting tools, but it is currently rather limited, because only one TaskTrackerInstrumentation can be added to a given TaskTracker and this objects receives minimal information about tasks (only their IDs). I propose enhancing the functionality through two changes:
> # Support a comma-separated list of TaskTrackerInstrumentation classes rather than just a single one in the JobConf, and report events to all of them.
> # Make the reportTaskLaunch and reportTaskEnd methods in TaskTrackerInstrumentation receive a reference to a whole Task object rather than just its TaskAttemptID. It might also be useful to make the latter receive the task's final state, i.e. failed, killed, or successful.
> I'm just posting this here to get a sense of whether this is a good idea. If people think it's okay, I will make a patch against trunk that implements these changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.