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