You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Mohammad Kamrul Islam (Commented) (JIRA)" <ji...@apache.org> on 2011/11/18 03:49:52 UTC

[jira] [Commented] (OOZIE-606) Oozie coordinator jobs behave incorrectly when given start-times in the past

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

Mohammad Kamrul Islam commented on OOZIE-606:
---------------------------------------------

This is a valid issue.
It could be presented differently: start is optional and the default value is NOW.

So Dave, do you plan to work on this?

                
> Oozie coordinator jobs behave incorrectly when given start-times in the past
> ----------------------------------------------------------------------------
>
>                 Key: OOZIE-606
>                 URL: https://issues.apache.org/jira/browse/OOZIE-606
>             Project: Oozie
>          Issue Type: Improvement
>         Environment: CentOS
>            Reporter: Dave
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> When starting a coordinator job with a start-time that has already passed, it queues up multiple workflow-jobs.  There should probably be a special constant to indicate that the coord-job should start submitting workflow jobs "NOW".  Consider the "start" parameter in the following:
> <coordinator-app name="coord_job" frequency="60" start="${coord:currentTime}" end="<some ending date>" timezone="UTC" xmlns="uri:oozie:coordinator:0.1">
> The meaning of this is that the start time is the current system time.

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