[ 
https://issues.apache.org/jira/browse/MAHOUT-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202917#comment-13202917
 ] 

Dmitriy Lyubimov edited comment on MAHOUT-946 at 2/7/12 11:08 PM:
------------------------------------------------------------------

bq. Some of these classes are also not AbstractJobs (though in some cases they 
should probably be converted - not sure it would make sense in all cases), some 
return some non-status value from the method that fires of the MR job, etc. 
Maybe a static util method would make more sense?

Static util method would probably make more sense. 

My current view of AbstractJob is that it is mixing two disparate concerns in 
one implementation: a Tool (pipeline bootstrap) in a sense of handing off the 
default Configuration, to which end it has a lot of helper methods, and a 
distinct MR job. Due to this, it is hard (or at least inconsistent) to use it 
as a base for a separate and highly specific step in multistep pipelines. 

Static method would not require AbstractJob as a base, so static drop-in is 
probably a better approach at this point.
                
      was (Author: dlyubimov):
    bq. Some of these classes are also not AbstractJobs (though in some cases 
they should probably be converted - not sure it would make sense in all cases), 
some return some non-status value from the method that fires of the MR job, 
etc. Maybe a static util method would make more sense?

Static util method would probably make more sense. 

My current view of AbstractJob is that it mixing two disparate concerns in one 
implementation: a Tool (pipeline bootstrap) in a sense of handing off the 
default Configuration, to which end it has a lot of helper methods, and a 
distinct MR job. Due to this, it is hard (or at least inconsistent) to use it 
as a base for a separate and highly specific step in a multistep pipelines. 

Static method would not require AbstractJob as a base, so static drop-in is 
probably a better approach at this point.
                  
> Map-reduce job status often left unchecked
> ------------------------------------------
>
>                 Key: MAHOUT-946
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-946
>             Project: Mahout
>          Issue Type: Bug
>    Affects Versions: 0.6
>            Reporter: tom pierce
>         Attachments: MAHOUT-946.patch, MAHOUT-946.patch
>
>
> I've run into a few places in Mahout where mapreduce jobs can fail and their 
> status won't be checked, so processing will continue on.  This sometimes 
> obscures the root problem.  I've tracked down a bunch of places where this 
> problem exists, and tried to fix the code to do something reasonable (return 
> -1 status code, throw exception, etc.) when jobs fail.

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

        

Reply via email to