Damon Cooper's BLOG
Viewing By Day : July 21, 2006 / Main
July 21, 2006
CFTHREAD and CFJOIN Proof Of Concept Tags

Our development engineers are called “Scientists” at Adobe which is cool because it means that we understand the importance of experimentation.  Like all good scientists, we hypothesize and test – some things make it into the product, others don’t – but we’re always innovating.  Here’s an example that Rupesh Kumar (CF Computer Scientist / Software Engineer) did on his own time after talking with a number of our customers about asynchronous processing in CF….not a lot of bells and whistles, mind you, but still a great Proof Of Concept of the CFTHREAD and CFJOIN tags.  I’ve also included a couple simple example templates to demonstrate the tags.

The first example copies a file 50 times files + sleep 200ms each time, and the second example launches 50 threads with CFTHREAD to do the same work and join back up at the end of the page with CFJOIN.  

This POC works with CF 7.0.2 (Standard or Enterprise).  While you can do multi-threading and asynchronous CFML with these POC tags, they don’t provide any of the fine-grained threading control you have with ColdFusion Event Gateways and the Asynchronous Gateway, for example.  So you don’t get thread pooling, control over how many worker threads can be active or pooled, metering on Gateway messages In/Out, or any of the other advanced capabilities of the Event Gateway architecture on CF7, but they do the basics: run stuff asynchronously in separate threads and allow for the use of local (thread-local) variables, allow access to shared scopes, etc.

A note on the simple example: you’ll want to modify both templates to copy a file (I use a “C:\baseline.txt” file) that exists on YOUR system to a directory that exists on YOUR system (I used “C:\____WORKFOLDER”).  I’d recommend turning on debugging so you can see the execution times yourself as well (much more dramatic that way).

Also note that spawned threads shouldn’t count towards Simultaneous Threads slots of the CF Server, so you shouldn’t need to adjust that setting to accommodate your extra threading.

Running the serialized example with debugging enabled yields this execution time block:

Execution Time

Total Time

Avg Time

Count

Template

10072 ms

10072 ms

1

C:\Inetpub\wwwroot\threadsynch_serial.cfm

0 ms

 

STARTUP, PARSING, COMPILING, LOADING, & SHUTDOWN

10072 ms

 

TOTAL EXECUTION TIME

red = over 250 ms average execution time

And running the CFTHREAD example with debugging enabled yields this execution time block:

Execution Time

Total Time

Avg Time

Count

Template

235 ms

235 ms

1

C:\Inetpub\wwwroot\threadsynch_cfthread.cfm

0 ms

 

STARTUP, PARSING, COMPILING, LOADING, & SHUTDOWN

235 ms

 

TOTAL EXECUTION TIME

red = over 250 ms average execution time

To be crystal clear, this little POC is not a CF product feature at this time.  This is just a simple and unsupported engineering Proof Of Concept.  I’d personally welcome your feedback and comments and I’d love to hear how folks might be able to use such functionality, but the POC’s are unsupported.  This is also no guarantee that the tag syntax will not change (perhaps drastically) in the future, and we have  no plans to update the POC as future major versions of CF come out, etc, etc.  CFTHREAD and CFJOIN tags may or may not make it into a future release, but that partly depends on feedback from customers.

One known issue/observation in playing with this personally: there appears to be a bug where if you don’t rejoin (using CFJOIN) all the threads you've spawned by the end of the page or you get a “500 Null” error (at least with my example, if you comment out the CFJOIN loop).  However, calling CFTHREAD (once) and skipping the CFJOIN appears to work fine.  Just so you’re aware.  You still get amazing parallelism as demonstrated above, even if your page waits for all threads to complete. Maybe if there’s interest we could fix that one thing, but for now, do play with these POC tags and let me know if they’re useful to you.

DOWNLOAD CFTHREAD POC & SAMPLES  (74k)

Damon


Using FDS + Flash Remoting In The Same Flex 2/CF App

You no longer need to try to merge or jam Flex jars and web app into a CF web app instance with Flex 2 and CF 7.0.2. With Flex 1.5, you wanted to do this in some cases, but this is no longer required now with Flex 2.

I suspect there's two reasons folks have been trying to do this: 1) either because of their Flex 1.5 + CF history (and they just assumed they needed to do the same with Flex 2), or 2) because they wanted to use FDS and Flash Remoting calls in the same Flex 2 app with CF as the back end. Ok, there is a rare third case where it might make sense, but the TechNote will be updated with that info to make that case very clear and make sure folks know that merging is definitely a highly specialized case, and NOT the norm that most people have to worry about.

Whatever the reason, I've observed some folks still trying to do this and running into difficulties in some cases.

The good news is that you can absolutely use Flex 2 FDS AND Flash Remoting in the same Flex 2 app SWF with CF 7.0.2 as the backend with "custom channels", but you do need to use setRemoteCredentials() independently on each (credentials don't automatically pass through Flash Remoting into FDS with in this case with custom channels, but this shouldn't be a big deal, just something to be aware of when coding your app).

There is a TechNote on the Adobe site that talks about merging Flex 2 FDS into the CF web application J2EE instance, but we're revising it shortly to make sure people realize they should have no reason to do this now with Flex 2 and to talk more about using custom channels in Flex 2 apps.

Thanks to Mike Nimer and Pete Farland for this.

Mike's blogged some details here: http://www.mikenimer.com/index.cfm/2006/7/19/Flex-Data-Server-and-CF-Flash-Remoting-together

Damon