[jira] [Commented] (FALCON-1677) Support re-tries for timed-out instances

["Narayan Periwal (JIRA)" <ji...@apache.org>]

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

Narayan Periwal commented on FALCON-1677:
-----------------------------------------

There are 3 ways in which we can implement retry for timed-out instances
1) Enable re-tries for timed-out instances by default with out any input from the user.
2) Second is in the retry tag add an attribute some thing like "onTimeout=true" for enabling the retries on timed out instances. The retry policies, delay and attempts remain the same for both retries on failure and timedout instances.
3) Have a separate retry policies, delay and attempts for failure and timedout instances. For this, we can introduce policies, delay and attempts attribute in the timeout tag as shown below:-
{code}
<timeout retry_policy="periodic" retry_delay="minutes(2)" retry_attempts="3">days(1)</timeout>
{code}


> Support re-tries for timed-out instances
> ----------------------------------------
>
>                 Key: FALCON-1677
>                 URL: https://issues.apache.org/jira/browse/FALCON-1677
>             Project: Falcon
>          Issue Type: Bug
>            Reporter: Pallavi Rao
>
> Currently, Falcon retries only on failure. We should extend support in case of timed-out instances too. Earlier, since we were relying on post-processing to notify the instance status, this was not possible. Now that Falcon relies on Oozie JMS notifications, we can support retries for timed out instances too.
> If a dataset is expected to get delayed for a long time, the user is currently forced to supply a large timeout value. This is an overhead in terms of Oozie having to poll for that long. If we introduce retries, the timeout can be a reasonable value with periodic/exponential back-off retries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)