The Woes of CFThread

Is anybody using <cfthread...> functionality?  Is it working well for you? I have been fighting for most of a month with <cfthread...> functionality and it is driving me batty. Run the application one time and it does all the processing, but does not output the results. Run it a second time and the system locks up and ColdFusion services must be cycled. Error trapping seems to be a crap shoot. If anything goes wrong in any of the spawned threads and all is lost.   Again ColdFusion has to be cycled. UHHG

> Is anybody using <cfthread...> functionality?  Is it working well for you? Yep. > I have been fighting for most of a month with <cfthread...> > functionality and it is driving me batty. cfthread is a VERY powerful tool. It also takes a lot of care to use correctly. > > Run the application one time and it does all the processing, but does > not output the results. That is expected. The output is stored in the thread scope for the thread itself. If you use the JOIN action (Which basically means, wait for these threads to end), you can get the output and look at it. This should be documented. (And let me add - be sure you have read the docs COMPLETELY!) > Run it a second time and the system locks up and ColdFusion services > must be cycled. Most likely it is something in your code. > Error trapping seems to be a crap shoot. Nope it isn't. Again, if you look at the thread data (if you use JOIN) you can determine if an error was thrown. Or you can use try/catch to log any errors. It is your responsibility to monitor what happens in the threads. > If anything goes wrong in any of the spawned threads and all is lost. > Again ColdFusion has to be cycled. Nope. See above. :) -- =========================================================================== Raymond Camden, VP of Software Dev, Broadchoice Email : ray@camdenfamily.com Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org

Raymond Camden wrote: > > That is expected. The output is stored in the thread scope for the > thread itself. If you use the JOIN action (Which basically means, wait > for these threads to end), you can get the output and look at it. This > should be documented. (And let me add - be sure you have read the docs > COMPLETELY!) >   Just to quickly address this point.  The expected output is not from the threads.  It's basically a simple 'I'm Done' statement after the thread loop and join.  The individual threads output is files written to the server.  What is wierd is that sometimes all the threads have processed as evidanced that all the expected files have been created and there are no threads shown in the CF Monitor.  But the output at the end of the file is not shown and the browser is still in waiting mode.

So then look in your code thats running in the thread. Is there something there that can hang? Do you have a deadlock of some sort? ----- Excess quoted text cut - see Original Post for more -----

> So then look in your code thats running in the thread. Is there > something there that can hang? Do you have a deadlock of some sort? I was thinking about that and knowing that he said the threads were writing files I was wondering about the number of threads he's spawning, the number of files being written, the size of those files, what webserver is in use (and whether or not it performs any file-locking and whether or not that file-locking might be invoked, even though I doubt it) and -- the relationship of all that information to the speed of the write-head on the drive. I wouldn't expect an overabundance of file-writing to cause the CF server to seize up completely and need to be restarted, but then I also don't know the whole configuration, am not an expert on server monitoring or hardware resources, etc. There just seem to be a large number of variables potentially affecting it. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 617.365.5732 http://onTap.riaforge.org/blog

Hello is this thing on? Raymond Camden wrote: ----- Excess quoted text cut - see Original Post for more ----- How are you using it?  Are there praticle limits on how many threads to create, how long thread generating code can be running?  Other factors to 'over using' this thread tool? ----- Excess quoted text cut - see Original Post for more ----- Any pointers on what these cares might be? ----- Excess quoted text cut - see Original Post for more ----- I have read the documents several times.  I understood the relationship between threads and output.  The output I was refering to was after the join statement and consisted of a "Done" string and a dump of the 'cfThread' structure.  I freely admit I do not completely understand all the ins-and-outs which is why I am experimenting.  But I have been very frustrated in that my attempts do not seem to yield predictable and repeatable results. ----- Excess quoted text cut - see Original Post for more ----- What could I add to the following thread to prevent it from generating hung threads that often require a service restart to clear?     <cfthread name="batchRenew_thread#i#" threadIndex="#i#" threadPathDate="#pathDate#" action="run">     <cfset var vRenewalReport = "">     <cftry>         <cfoutput>#threadIndex#: #threadPathDate#</cfoutput>                <cfset thread.foobar = threadIndex & ": " & threadPathDate>            <cfcatch type="any">             <cflock name="treadLogLock" timeout="5" type="exclusive">                     <cfset thread.cfcatch = duplicate(cfcatch)>             </cflock>         </cfcatch>     </cftry>     </cfthread>

Just glancing at this code snippet... I haven't done any work with cfthread recently, but I have implemented it in the past... I wouldn't expect the var keyword at the top to work. The thread does its own encapsulation that's more similar to a custom tag, so I would expect the var keyword to produce an error. I believe that's a parser error, which happens before compiling the template, so the template with the cfthread in it shouldn't even run. But then I've never tested this either. Also I wouldn't lock that catch - it doesn't need a lock around it as far as I can tell and if it did, then I suspect the lock would need to be outside the try tags, because putting it inside the catch will mean you still have a race condition. But I don't think a race condition exists there in the first place because of the cfthread tag's encapsulation. You also shouldn't need to duplicate the cfcatch. I don't think it'll hurt anything, but it shouldn't be necessary. hth, ike ----- Excess quoted text cut - see Original Post for more ----- -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog