Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Michelle Meadows
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Michelle Meadows

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

By Ben Nadel on
Tags: ColdFusion

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.



Looking For A New Job?

Ooops, there are no jobs. Post one now for only $29 and own this real estate!

100% of job board revenue is donated to Kiva. Loans that change livesFind out more »

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

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
NEW: Some basic markdown formatting is now supported: bold, italic, blockquotes, lists, fenced code-blocks. Read more about markdown syntax »
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.