May 20, 2019
CF2018 and requestTimeOut
Comments
(11)
May 20, 2019
CF2018 and requestTimeOut
Newbie 1 posts
Followers: 0 people
(11)

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?

11 Comments
2020-07-21 15:55:54
2020-07-21 15:55:54

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

Like
2020-05-26 16:43:18
2020-05-26 16:43:18

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.

Like
(2)
>
altascene
's comment
2020-05-27 19:43:36
2020-05-27 19:43:36
>
altascene
's comment

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.

Like
>
Eddie Lotter
's comment
2020-05-28 19:00:18
2020-05-28 19:00:18
>
Eddie Lotter
's comment

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.

Like
2019-12-24 10:40:37
2019-12-24 10:40:37

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.

Like
(1)
>
karma007
's comment
2019-12-24 13:30:34
2019-12-24 13:30:34
>
karma007
's comment

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.

Like
2019-05-20 14:49:27
2019-05-20 14:49:27

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

Like
(1)
>
Charlie Arehart
's comment
2020-04-16 12:07:53
2020-04-16 12:07:53
>
Charlie Arehart
's comment

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

Like
2019-05-20 14:27:05
2019-05-20 14:27:05

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.

Like
(2)
>
Miguel Fernandez
's comment
2019-05-20 14:50:26
2019-05-20 14:50:26
>
Miguel Fernandez
's comment

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.

Like
>
Charlie Arehart
's comment
2019-05-20 15:07:58
2019-05-20 15:07:58
>
Charlie Arehart
's comment

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

Like
Add Comment