We recently converted a bunch of old cfm scheduled tasks to instead run as components implementing the ITaskEventHandler. These tasks make SOAP requests via CFHTTP and the requests can be lengthy. The CFHTTP tag itself has a timeout of 600 seconds (10 minutes). I've also set the scheduled task to have a timeout of 600 seconds. The requesttimeout set in coldfusion administrator is only 60 seconds, but the application.cfc that is used by all of the scheduled tasks has a much longer requesttimeout of 2500 seconds. When the tasks were executed by the scheduler as .cfms, CFHTTP would respect the longer timeout (the docs say it takes the lesser of the server/app timeout and the cfhttp timeout, so at the very least, 600 seconds). When converted to CFCs and executed via REST request, CFHTTP also respects the 600 second timeout. But when executed by the scheduler now that they are CFCs, CFHTTP times out after 60 seconds. I've tried adjusting the CFHTTP timeout, tried adding requesttimeout=600 cfsetting tags all over the place (OnRequestStart in the application CFC, at the root of the application CFC, in OnTaskStart and in the Execute function in the task CFC, etc) but to no avail. The timeout set in coldfusion admin is always used - I verified this by temporarily adjusting the timeout value there. I am looking for one of two things: either the correct place to put the cfsetting requesttimeout override, so CFHTTP uses the lesser of that and the 600 second timeout set on CFHTTP itself, or more information on the other option presented in the CFHTTP documentation which says: "If the client specifies a time-out in the URL search parameter (for example, ?RequestTime=120) ColdFusion uses the lesser of the URL time-out and the timeout attribute value". I have tried appending a 'RequestTime=600' url param to the URL specified in the CFHTTP request, but this doesn't seem to make a difference. (also how would this even work? Is 'RequestTime' the actual variable name it's looking for or just an example? This is never referenced anywhere else in the CF docs). Thank you!

Fred Flintstone asks if it's actually requestTimeout 😉

@Dave Merrill I've tried 'requesttimeout' 'timeout' and the the doc's suggested 'requesttime' and none seem to change anything. (thank you for the suggestion!)

Why would you even need to do either of those two things? Cfscheduler enables you to set the start-time and end-time of the task. It is also possible that I don't yet understand the problem. In any case, there is a way to treat REST requests as a separate category of requests in Application.cfc, namely:

public any function onRESTRequest(string cfcname, string method, struct args) {

var RESTResponse = invoke(arguments.cfcname, arguments.method , arguments.args);

return RESTResponse;

}

I am guessing that fitting cfsetting somewhere in there would be an answer.

@BK BK The issue I'm seeing is more with CFHTTP when called within an ITaskEventHandler task specifically. If the task is run as a REST call, CFHTTP respects the cfsetting requesttimeout tag, and if run as a .cfm, CFHTTP respects the cfsetting requesttimeout tag. But when the task is setup as a ITaskEventHandler, and the cfsetting tag is placed any of the places I listed (including in the execute function directly above the CFHTTP tag), it's ignored. Because it's ignored, the docs state the lesser of the request timeout set at the server level in CF Administrator and the timeout set in the CFHTTP tag are used. Those values are: 60 (in CF Admin) and 600, so 60 is used instead of the much higher value that should be overridden by the cfsetting tag. This effectively makes it impossible to set CFHTTP to use any timeout value other than the one set at the server level when using the ITaskEventHandler. I'm thinking about creating a simple-to-reproduce example and submitting it to Adobe as a bug. For now, we've switched these longer-running tasks to run as REST requests, but then you lose all the functionality gained by using an ITaskEventHandler (misfire handling, task-specific error handling, ontaskstart/ontaskend functions).

Fair enough.