hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1313) JobInProgress should be public (or implement a public interface)
Date Tue, 01 May 2007 23:48:15 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492988

Doug Cutting commented on HADOOP-1313:

The standard public API for such things is JobClient, not JobTracker.  Is that not sufficient?
 It may not be, but I think that's the thing to change, rather than exposing stuff through
JobTracker directly.  To my thinking, the only reason that JobTracker is a public class is
so that one can start and stop the daemon.  Other interaction should be through JobClient.
 Could that work for you?

> JobInProgress should be public (or implement a public interface)
> ----------------------------------------------------------------
>                 Key: HADOOP-1313
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1313
>             Project: Hadoop
>          Issue Type: Bug
>          Components: mapred
>            Reporter: Michael Bieniosek
> I'm trying to get programmatic access to hadoop job/task status through the JobTracker
> I notice that JobTracker returns a JobInProgress object in several public methods (runningJobs,
getJob).  However, JobInProgress is a package-access class.  So, oddly, I can get JobTracker.getJob(),
but I can't store the result as a JobInProgress (I suppose I could store it as an Object,
but then I couldn't upcast it back).  
> The JobInProgress object gives me useful information about jobs, so I don't think making
runningJobs/getJob not public is a good idea.  I get the idea from HADOOP-28 that JobInProgress
is not public because nobody wants to maintain compatibility in this class across hadoop versions.
> So it would probably be best if we created public interfaces that JobInProgress and TaskInProgress
implement.  I only care about the accessors, so maybe from JobInProgress we could expose (getProfile,
getStatus, get*Time, {finished,desired,running}{Maps,Reduces}, getMapTasks, getCounters) and
from TaskInProgress (isRunning, isComplete, isFailed, isMapTask, numTaskFailures, numKilledTasks,
getProgress, getCounters).
> Any thoughts?

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

View raw message