A personal example is in the area of administrative reporting vs general use.
I'd want any request of general usage to timeout, throw an error to the client and release the connection - were something unknown to happen that caused some process to hang and hold up the CF engine from finishing within a universal period. However, in the case of an administrative or other "rare-process" use - perhaps requesting some long-winded report known to take about minute or more to query and present - or waiting for the CF engine to FTP down a file from an archive elsewhere and then send it over; I use a CFSETTING command to tell the CF engine to wait longer than normal in this case. Yep, mine are exactly the same examples you wanted out of the equation... I think that the cfsetting requesttimeout tag gave ColdFusion a total "start to finish": How long to wait for the supporting systems to deliver resources, for CF/BD to do it's computational magic, and for the client to acknowledge receipt of it the last packet. It's not setting individual limits on any one server or client sub process. Yes, it's lazy. Or perhaps they wanted a safety valve for the unknown user invoked Java process, when they wrote it into a tag for MX. I think you're saying that there exist better methods for developers to trap for these exceptions: place timeouts inside the queries, datasource, http and ftp tags as needed and apply one single global "worst case" timeout to the entire server (method TBD)? And if so, I suppose I agree. Except that I would feel far more comfortable with a "start low - exception high" paradigm than a "start high - exception low" one, when it came to a bunch of cowboys writing code for my app's. But regardless, it's still a compatibility issue that should be addressed or at least documented. Folks need to know that requesttimeout (whether in the url scope or the cfsetting tag) will work the way it has in CF for generations of versions. Or they need to know (perhaps why not, and) what to rewrite. I'm afraid that if I keep talking about compatibility documentation too much, I'll find myself as a volunteer soon. Al Alan Williamson wrote: > interesting. > > Its something that sounds easy, but could be quite 'hard' as it could > leave a lot of things in a undeterminate state. > > What could hold things up? > > Surely if its a CFHTTP you can add a timeout, or a database, then you > set the maximum time a query has to run before the pool removes it. > > So taking that out of the equation, help me understand what other areas > you would want to catch for? Give me an example please? > > --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
