Requestimeout in CF2018 using the scheduler
We have just migrated from CF11 to CF2018 and discovered that it not possible to set the timeout option using the scheduler.
It looks like setting the requesttimeout option in the requested cfm page doesn’t solve the problem. The scheduler still ends up with an timeout exception.
What is the correct way of specifying the timeout value using the scheduler in CF2018?
Newbie
1 posts
As per https://helpx.adobe.com/coldfusion/deprecated-features.ug.html requestTimeout attribute of the cfschedule tag is only deprecated and unsupported but in reality removed in 2021 and it is not working
Hi, I recently upgraded from CF2016 to CF2018 and all of my scheduled tasks have cfsetting requesttimeout in them. But they are still timing out after 60 seconds (CF-wide setting). Did this get fixed in any of the hotfix updates? I’m almost caught up with them – I still need to install Update 8-10 yet.
I am running into this issue right now. Task works fine in the browser. Takes around 80 seconds to run. It will not complete when using the scheduler. When I write the output to a file, it just says Connection Timeout. I have a cfsetting requesttimeout = 300 on the page (I even tried 10000, but no difference).
My vote would be to add the timeout option back to the Scheduler task configuration page. <cfsetting RequestTimeout = “number_of_seconds”> does work but, if you have a task that increases in runtime over time, you are required to make a programming change, as opposed to an administrative one. I would much prefer the latter.
Your application can read a configuration file just as easily as the scheduler. There is no need to hardcode a timeout value, especially if you intend to change it over time.
But Eddie, using requesttimeout in the CFML won’t work if a scheduled task needs to call out to some non-CFML page.
As for a “reason” why the CF Admin previously had a means to set a timeout for scheduled task calls, my assumption is that it was in case the page being called either a) would have timed out (relative to CF’s other timeout settings) and you wanted to override that, or b] could have run “forever” if there was no CF admin timeout, and one wanted to impose such a limit.
But back to the original point in the post here, amigaNOR was saying that it didn’t matter WHAT timeout was set for the CF page being called (if one was being called as a sched task): if the sched task reaches some internally defined time, the task fails.
Something does seem amiss, or I’m open to more clarifications from anyone with knowledge of what’s going on.
Thanks Adobe for breaking every MURA CMS 6 website with this ridiculous attribute removal. Why couldn’t you have just kept it deprecated? I mean all Adobe needed to do, is just ignore this attribute. Simple. Instead, they have destroyed backward compatibility.
Care to elaborate? That’s the first mention of a Mura issue here. Is it that some part of a Mura site fails? Your statement suggests it’s a grave impact. Help readers to know (whether they are fellow users of Mura or not).
And have you opened a ticket about this at tracker.adobe.com? Offer the id here and folks can add votes.
Same with any report to Mura? After all, cf2018 is now over 18 months old. It would be surprising if this couldn’t have been addressed in the Mura code base before now. But again, we readers don’t know how big a problem this is based on that first comment of yours.
As always, just trying to help–in this case you, fellow Mura users, the CF and Mura teams and others just reading along.
It looks like amigaNOR was saying they had indeed already set the timeout on the page being called. What I find interesting is their assertion that that is not doing the job as it did in CF11.
Can you confirm, amigaNOR, that a page running long in CF11, when called a a scheduled task without a timeout on the task, really would somehow timeout sooner in CF11 (when that page had a cfsetting requesttimeout on the page itself)? I would not expect it to be so. Maybe instead you’re just recalling that it “seemed never to happen before” with CF11.
But really, it would seem you should turn your attention to why the page is running long in CF2018. That’s the real problem to solve.
It is lamentable to some that the timeout was removed from scheduled tasks. But the fact that CF pages don’t “end” when the requesttimeout is set (in the page or in the admin) is not really new. I blogged about it several years ago: https://www.carehart.org/blog/client/index.cfm/2010/10/15/Lies_damned_lies_and_CF_timeouts
>But really, it would seem you should turn your attention to why the page is
>running long in CF2018. That’s the real problem to solve.
The page does some heavy batch processing, and is not running longer in CF2018. In CF2018 there is no way to set the timeout, so CF scheduler will always report a Connection Timeout. Adding <cfsetting requestTimeOut = “10000” > to the page does not resolve the problem.
Even if CF scheduler always reports a Connection Timeout, the page continues to process.
The requestTimeoutattribute of the cfschedule tag has been deprecated since CF 11. It was removed in CF 2018. You can see that in the note on this documentation page:
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfschedule.html
Without this attribute I believe the timeout falls back to the overall CF request timeout setting. Of course you can override that timeout by adding a `<cfsetting RequestTimeout = “number_of_seconds”>` to the page that is being executed.
Sorry, Miguel. I meant my comment above to be a reply to yours. Somehow the UI here instead caused me to create it as a new comment.
No worries Charlie. I have had issues with the UI here as well.
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
