Skip to main content
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Tim Cunningham
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Tim Cunningham ( @TimCunningham71 )

CFSetting RequestTimeout Updates Timeouts, It Does Not Set Them

Published in Comments (10)

That title probably doesn't make a lot of sense. What I mean by that is that when you use a CFSetting tag and set the RequestTimeOut attribute, the value you assign does not just apply to everything going forward - it applies to everything going forward in the context of everything that has already happened. Ok, maybe that doesn't clear anything up. What I mean to say is that the RequestTimeOut attribute does not determine the amount of time left, it determines the amount of processing time allowed in total.

Here is a demo to help explain what I am saying. For this example, I use a ColdFusion user defined function named KillTime(). This function simply runs a loop until a given amount of time has passed:

	hint="I kill time for the given miliseconds.">

	<!--- Define arguments. --->
	<cfargument name="MS" type="numeric" required="true" />

	<!--- Get start and end tick out values. --->
	<cfset var intStart = GetTickCount() />
	<cfset var intEnd = (intStart + ARGUMENTS.MS ) />

	<!--- Loop until this time is killed. --->
	<cfloop condition="(GetTickCount() LT intEnd)">

		<!--- Just try to kill some processing time. --->
		<cfset intStart = (intStart * Pi()) />


	<!--- Return out. --->
	<cfreturn />

Now, with that function in mind, here is the test code:

<!--- Set the current time out to be 3 seconds. --->
<cfsetting requesttimeout="3" />

	Get the millisecond start time for page processing
	(so that later on, we can check to see how long
	the page ran overall).
<cfset intStart = GetTickCount() />

<!--- Try to kill some time. --->

		Here, we are killing time - 4 seconds to be
		approximate. This will exceed the request time
		out set above (3 seconds) and will throw an error.
	<cfset KillTime( 4000 ) />

	<!--- The KillTime() method call has timed out. --->

		First Timeout!<br />

			In an attempt to "recover" from this time out,
			update the request time out to be six seconds.
		<cfsetting requesttimeout="6" />

		<!--- Try to kill some more time. --->

				We are going to try and kill about four
				seconds. If this is in terms of the six-second
				timeout set above, this should NOT timeout.
				However, if this is in the context of the
				overall page time (including previous kill time
				calls), then this will timeout.
			<cfset KillTime( 4000 ) />

			<!--- The KillTime() method has timed out. --->

				Second Timeout!<br />




Total Time: #(GetTickCount() - intStart)#

That gives us the following output:

First Timeout!
Second Timeout!
Total Time: 6016

Now, if you look at the code, and the output, you will see that both calls to KillTime() threw timeout exceptions. The first one is straight forward - we tried to kill 4 seconds when the current request timeout only allowed 3 seconds. But, then we set the request timeout to be 6 seconds. In this second KillTime() request, we try to kill 4 seconds. If the previous 6 second timeout was a NEW timer, then this would not timeout (4 is less than 6). However, this second KillTime() method times out. This shows us that request timeout settings don't "add" time, they merely update how much total time is allowed.

Aside from the fact that this gives us a little more insight into using multiple CFSetting tags (which might not be totally obvious - it wasn't to me), it also proves that when a tag or block of code throws a request timeout exception, ColdFusion doesn't die right away - there is some wiggle room in which to recover or potentially add more execution time.

Want to use code from this post? Check out the license.

Reader Comments


This would make sense, Ben, as ColdFusion uses output buffering by default, and you must explicitly tell it to flush the contents of the buffer. This is unlike language like PHP, for example, which flush content out as it is processed, and you must explicitly tell it to buffer output if you wish for that behavior.


I cannot say with any authority, however I have spent a little time writing my own language interpreters, and found that when assembling my page into my output buffer anytime I found a command that would modify program execution settings, I would put those into my script's environment settings, and overwrite any existing value.

That is essentially what I figure ColdFusion is doing. This is a setting that affects this request's processing environment, and it isn't "queuing" them up, but simply storing the last value.

Once again, no authority, just assumtions based off behavior and my own code in the past. *shrug*


What happens if you remove the second requesttimeout setting? Since you've already caught the exception and handled it, how much more wiggle room does CF allow you?


If I take out the second CFSetting, this is the output:

First Timeout!
Second Timeout!
Total Time: 3031

Looks like the second KillTime() method times out immediately, is caught, and then lets the rest of the page process (which only takes a few milliseconds).

In my experience, the "wiggle room" is generally NOT enough time to do anything much like send an email that has much of any processing time to it (ex. CFDump var="CGI").


This is an interesting piece of code.

I would have expected that setting to tell the CF server how long to wait until pulling the plug on the request (kind of what it says on the box). I would not expect it to throw a catchable exception, because it should have ceased processing the request completely.

Good to know, in an esoteric sort of way. Good work.



If what you are suggesting is that the second killtime() still dies because the original requesttimeout (3 seconds) has ended and therefore the second requesttimeout (6 seconds) won't be able to update any remaining time, why does making the second timeout 60 seconds rather than 6 work (not timeout) the second killtime()?

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel