Passing A Timeout To .get() Will Not Override An Existing Future Timeout In ColdFusion 2018
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
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
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.