hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matei Zaharia (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MAPREDUCE-1881) Improve TaskTrackerInstrumentation
Date Tue, 10 Aug 2010 05:36:20 GMT

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

Matei Zaharia commented on MAPREDUCE-1881:
------------------------------------------

Sure, I can do that. I think the biggest risk with the composite object is adding a method
to TaskTrackerInstrumentation that we forget to add in the composite. While this is bad, it
would arguably get noticed faster if the composite object is used by default than if it isn't.
Any other opinions on this? Any other reasons to avoid it?

I really see the composite object as not much different than having a for loop at every call
site. Supporting multiple instrumentation objects is clearly useful (the same way that most
classes in the JDK with events support multiple listeners). The question then is how to do
it. Since the instrumentation interface isn't designed in such a way that an implementation
knows who called it (i.e. can tell whether it went through a composite object), it seems OK
to use a composite object to route calls to a list of implementations.

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


Mime
View raw message