hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Lu (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MAPREDUCE-1881) Improve TaskTrackerInstrumentation
Date Wed, 11 Aug 2010 08:21:19 GMT

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

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

I have no issue with the statusUpdate method. I got where you're coming from :) But I question
"many users will want to do the same thing". I'm curious about "many useful instrumentation
classes being written". Adding features (especially redundant ones), IMO, doesn't necessarily
make Hadoop better but rather bloated and harder to maintain. You know, "perfection is attained
not when no more can be added, but when no more can be removed."

Another thing about the patch is that if the instrumentation class is specified as an empty
string, it silently defaults to the composite class with a empty list (essentially a noop
instrumentation), which is a behavior change from the existing behavior: an exception would
be thrown.

> 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-v2b.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.


Mime
View raw message