portal entry

<p>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:</p><p><a href="https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfschedule.html" rel="nofollow">https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfschedule.html</a></p><p>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.</p>

Comment by Miguel Fernandez

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: <a href="https://www.carehart.org/blog/client/index.cfm/2010/10/15/Lies_damned_lies_and_CF_timeouts" rel="nofollow">https://www.carehart.org/blog/client/index.cfm/2010/10/15/Lies_damned_lies_and_CF_timeouts</a>

Comment by Charlie Arehart

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.

Comment by Charlie Arehart

No worries Charlie.  I have had issues with the UI here as well.

Comment by Miguel Fernandez

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.

Comment by karma007

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.

Comment by Charlie Arehart

<p>>But really, it would seem you should turn your attention to why the page is <br />>running long in CF2018. That’s the real problem to solve.</p><p>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.</p><p>Even if CF scheduler always reports a Connection Timeout, the page continues to process.</p>

Comment by amigaNOR

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.

Comment by altascene

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.

Comment by Eddie Lotter

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.

Comment by Charlie Arehart

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

Comment by The Idea Bulb