Configure Failed Task Retry Attempts

Xavier Ona shared this idea 4 years ago
Idea Logged

Can we implement a configuration to limit the amount of retries occurs when a task fails?

In example, a recent FTP broadcast task scheduled as a daily task is attempting to complete every 8 to 10 minutes due to a failure.

Comments (11)

photo
1

Hi Xavier,

Thanks for reaching out with your suggestion. I've run into this scenario a couple of times, and think this is an excellent candidate for future Enhancement. I've raised this as an Enhancement Request and the progress can be monitored here.

In the meantime, I'd recommend configuring some alerts to failed tasks so situations like this can be identified and remedied manually. This can be done by enabling the 'Broadcast Failure Task' under 'Administration' > 'Configuration' > Mail Icon > 'General Settings'.

This will create a task any time a broadcast fails to be sent. This task is created for the group specified in 'Broadcast Failure Task Recipient'. You can also check the 'Timeline Updates' selection under 'Notification Settings' to get an e-mail notification when a task is created.

This will allow you to identify if any tasks are failing multiple times a day, and then to determine whether they need to be adjusted from there.

I understand this isn't a good permanent solution, but it does give some type of notification in the mean time.

Thanks,

Ryan

photo
1

Hi Ryan,

Can you please let us know if this enhancement has been implemented in any recent release?

We would like to have some retry attempts when a broadcast fails either email or ftp.

Thanks,


Bharath

photo
1

Hi Bharath,

Thanks for checking in on this. I can confirm that this Idea is still set as logged and a decision has not yet been made as to whether this may be implemented in a future version.

Thanks,

Ryan

photo
1

Hi Ryan,


Can you please share the RFE ID with us?


Regards

Bharath

photo
1

Hello Bharath,

Regarding this issue please refer to ticket number 5989.

Thanks,

Jared

photo
1

Hello,

any News on this? We're using the yellowfin builtin BMC (where Bharath Kumar comes from, we know us).

I'm wondering in such a system potentially connecting to a lot of other server where connection can fail due to temp. network problems or network latencies there should be a (best: configurable) retry mechanism i.e. like business objects.To show you the pain - we had this morning an smtp issue and 489 reports were not sent out. In such case you have lost with yellowfin - or know what you will do the rest of the day manually beside telephoning with user.

Best regards from the pain frontRolf

photo
2

Hi Jared,

I would like to know whether this idea has been implemented yet or not.

Thanks

Pratiksha

photo
1

Hi All,

Unfortunately at this time I am unable to provide an ETA. I will keep this ticket updated with any progress made.

Thanks,

Jared

photo
1

Hello,

to have a workaround for this - is it possible to use that mechanism for volatile data source? https://www.yellowfinbi.com/blog/2012/10/yfcommunitynews-volatile-data-sources-in-business-intelligence-120402Or to disable/pause such delivery jobs - i.e. detect per (whatever) script a net issue, inform the admins, pause the delivery of the created reports and after resource is back online to send the reports delayed?

photo
1

Hi Rolf,

Currently the scheduler doesn't have a built in retry function. All attempts to run a report (even for schedules) is based on the connection configuration.

If a report fails to run, it will mark the task as failed, and won't attempt again until it's next occurrence. Note: There is an exception to this, in that, if the instance is restarted and Yellowfin detects the schedule had failed within a given period, then it will re-attempt on startup. This article can be helpful in diagnosing your situation: https://community.yellowfinbi.com/knowledge-base/article/volatile-data-sources-what-is-it-and-when-do-i-need-it

We should note here that if Volatile Sources are enabled, this will impact any running of the reports. Meaning, if a schedule tries to run the report and the Volatile Sources says to try 10 times, the schedule will stop until those 10 tries are completed.

If an issue has occurred due to the network/SMTP, then broadcast failure notifications should be configured. This will make you aware of such cases as they occur. If these do happen you can select multiple tasks in the schedule management window and hit 'Run Now' to run them all. You can also use the schedule filters (the drop down menus) to only highlight failures for retry:

/068dbfff7defb863f3c975de30e9ed80

Please let me know if you have any questions regarding this.

Thanks,

Jareed

photo
1

Hi Rolf,

I wanted to reach out to see if the information provided was useful and if you had any further questions regarding this.

Regards,

Jared

photo
1

Hello,

that sounds interesting - we'll give it a try.

Although, when email delivery fails cause the smtp connection is temp. down cause of a network issue / long latency the (immediate) failure notification (via email?) makes no sense - there from admin perspective a "summary / digest" would be helpful - or a bit of a delay.

We help us in between with a pshell-script which simply counts the errors in the email.log.

Add. this "hit 'Run Now' to run them all" - we'll check.


Thank you,

Rolf

photo