[
https://issues.apache.org/jira/browse/HADOOP-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Grey updated HADOOP-2306:
-------------------------------
Description:
I would like some of my jobs to do other activities after the map reduce is
done, but before any dependent jobs would start.
I think this could be accomplished in a many ways, here are three that I could
think of:
A) mark the checkRunningState method as protected, so that a subclass could
override it and only set the status to SUCCESS after the extra activity is done.
B) Add a handler/event mechanism that triggers events before state changes.
Handlers of those events could "cancel" the state change if they needed to (ie:
if something failed)
C) Provide a protected template method that is executed before each state
change that subclasses can override.
was:
I would like some of my jobs to do other activities after the map reduce is
done, but before any dependent jobs would start.
I think this could be accomplished in a many ways, here are two that I could
think of:
A) mark the checkRunningState method as protected, so that a subclass could
override it and only set the status to SUCCESS after the extra activity is done.
B) Add a handler/event mechanism that triggers events before state changes.
Handlers of those events could "cancel" the state change if they needed to (ie:
if something failed)
C) Provide a protected template method that is executed before each state
change that subclasses can override.
fixed typo
> Modify org.apache.hadoop.mapred.jobcontrol.Job class to allow actions before
> status changes
> -------------------------------------------------------------------------------------------
>
> Key: HADOOP-2306
> URL: https://issues.apache.org/jira/browse/HADOOP-2306
> Project: Hadoop
> Issue Type: Improvement
> Components: mapred
> Reporter: Jason Grey
>
> I would like some of my jobs to do other activities after the map reduce is
> done, but before any dependent jobs would start.
> I think this could be accomplished in a many ways, here are three that I
> could think of:
> A) mark the checkRunningState method as protected, so that a subclass could
> override it and only set the status to SUCCESS after the extra activity is
> done.
> B) Add a handler/event mechanism that triggers events before state changes.
> Handlers of those events could "cancel" the state change if they needed to
> (ie: if something failed)
> C) Provide a protected template method that is executed before each state
> change that subclasses can override.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
