Skip to main content
Ben Nadel at CFinNC 2009 (Raleigh, North Carolina) with: Mike Brunt and Dan Wilson
Ben Nadel at CFinNC 2009 (Raleigh, North Carolina) with: Mike Brunt ( @cfwhisperer ) Dan Wilson ( @DanWilson )

Passing A Timeout To .get() Will Not Override An Existing Future Timeout In ColdFusion 2018

By on
Tags:

CAUTION: This is just a note to self; building my mental model around Futures in ColdFusion 2018.

This is just a quick post to document a behavior of .get() on a Future in ColdFusion 2018. Calling .get() will cause the page to block and wait for the Future to be resolved. And, as part of that call, you can provide a timeout (in milliseconds) that will determine how long the page should block and wait before it throws a Task Timeout error. One thing to be aware of, however, is that the timeout you pass to .get() will not override the existing timeout - if there is one - on the Future for which you are waiting.

To see what I mean, take a look at this code:

<cfscript>

	future = runAsync(
		function() {

			sleep( 200 );
			return( "Slow to rise." );

		},
		50
	);

	// CAUTION: This will ERROR. The 500 timeout here does NOT OVERRIDE the 50 in the
	// runAsync() call. Once the runAsync() timeout is defined, any value provided in
	// the .get() call will not affect it.
	writeOutput( future.get( 500 ) );

</cfscript>

In this case, we have a future that will require 200ms to resolve. But, we've passed a 50ms timeout to the runAsync() method. As such, the future should "timeout" on it's own. And, if we attempt to use a 500ms timeout in the subsequent future.get() call, we will discover that is has no bearing on the outcome: the Task will timeout:

coldfusion.runtime.async.TaskTimeoutException: Task timed out.

In the above code, we were trying to increase the timeout. But, the same behavior occurs if you try to decrease the timeout:

<cfscript>

	future = runAsync(
		function() {

			sleep( 200 );
			return( "Slow to rise." );

		},
		500
	);

	// CAUTION: This will NOT ERROR. The 50 timeout here does NOT OVERRIDE the 500 in
	// the runAsync() call. Once the runAsync() timeout is defined, any value provided
	// in the .get() call will not affect it.
	writeOutput( future.get( 50 ) );

</cfscript>

In this case, we have a future that will run successfully with a 500ms timeout. And, if we try to override that timeout with a 50ms timeout in the subsequent .get() call, we will once again see that it has no bearing: the task runs successfully and produce the following ColdFusion output:

Slow to rise.

To be clear, I'm not saying this is a bug - it's just a behavior that I wanted to document for myself in order to build a better mental model of Futures in ColdFusion 2018.

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

Reader Comments

1 Comments

Hi Ben,

Always immensely enjoying your blogs and have found many of them useful for my day-to-day work.

While searching for some ColdFusion specific function arguments, I came across this recent post. It must be great to use ColdFusion 2018, as you mention "Calling .get() will cause the page to block and wait for the Future to be resolved"

If only...

Piet

27 Comments

Hi Ben,

Greetings and Good News!!

We have done some recent changes to ColdFusion 2018 Async Framework - the first level then(), error() and their corresponding timed versions are unblocking now. It should be available as a part of ColdFusion 2018 update.

I will keep you posted on the update details.

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