Additional to Mark's observation, as for why it's seeming to timeout on CFLOOP, CF often shows the timeout occurring on a tag that *follows* that which may have caused the request to run long (often, a cfquery or cfhttp, etc.) So you often can't use the tag shown to know wwere the timeout occurred. I discuss that more (as well as some other surprising info on CF timeouts) in an entry:
http://www.carehart.org/blog/client/index.cfm/2010/10/15/Lies_damned_lies_an d_CF_timeouts All that said, I hear you saying that the real confusion is that it's timing out *before* you think it should. Given that it's happening on the CFLOOP (and not a tag like CFQUERY or CFHTTP, which can have its own TIMEOUT attribute), I would propose that you simply *have to* have something controlling that timeout more broadly, and it's either the CF Admin "timeout requests" setting or a CFSETTING REQUESTTIMEOUT. I saw you say later in the thread that you don't use the latter. Well, you may and not realize it. Of course, it could be set anywhere in the life of the request before this code runs, so it could be an include, or in a CFC called, or in the application.cfm./cfc or files they would call. Note that the application.cfc offers an app-level controllable equivalent as this.timeout (not this.requesttimeout). Given all that, I'd propose you could at least rule things out by searching your codebase for any reference to requesttimeout (to find any use of CFSETTING) and then search all application.cfcs for this.timeout. Finally, and assuming you find none (or would swear to it without checking), going back to the Admin timeout setting, I realize you think it's set larger, but here's a possibility: you may be looking at an Admin that is NOT the one controlling the code you're running. For instance, if you have multiple instances, you may be inadvertently seeing the CF Admin for one instance, while your code is running in another (with its own other Admin). I see it more often than you may believe. :-) Again, worth ruling out. Hope that helps. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Mark Mandel Sent: Tuesday, February 01, 2011 10:37 PM To: [email protected] Subject: Re: [cfaussie] The request has exceeded the allowable time limit Tag: CFLOOP You page is exceeding the request time-out. The error is misleading, just because the Tag displayed just happens to be wherever the code lands when the timeout occurs. You may want to increase the request timeout on that page, or drop some <cftimers> in place, and work out what is taking so long, and attempt to speed it up (or both!) Mark On Wed, Feb 2, 2011 at 2:34 PM, Gavin Beau Baumanis <[email protected]> wrote: Hi there everyone, We have an issue with some long running SQL in our application. The error is; The request has exceeded the allowable time limit Tag: CFLOOP The docs don't seem to indicate that the CFLOOP tag even has a timeout attribute. The stack trace (below) seems to indicate that the request is timing out - but the timeout set in the CFAdmin is 1000 seconds (16.66 minutes) and the error is being thrown before then. coldfusion.runtime.RequestTimedOutException: The request has exceeded the allowable time limit Tag: CFLOOP at coldfusion.runtime.CfJspPage.checkRequestTimeout(CfJspPage.java:2907) at cfweeklypatientvisits_bereaved2ecfm309418466._factor43(/var/www-vhosts/palca re/teomanga/patient/weeklypatientvisits_bereaved.cfm:531) at cfweeklypatientvisits_bereaved2ecfm309418466._factor64(/var/www-vhosts/palca re/teomanga/patient/weeklypatientvisits_bereaved.cfm:387) at cfweeklypatientvisits_bereaved2ecfm309418466._factor66(/var/www-vhosts/palca re/teomanga/patient/weeklypatientvisits_bereaved.cfm:386) at cfweeklypatientvisits_bereaved2ecfm309418466._factor67(/var/www-vhosts/palca re/teomanga/patient/weeklypatientvisits_bereaved.cfm:78) at cfweeklypatientvisits_bereaved2ecfm309418466._factor68(/var/www-vhosts/palca re/teomanga/patient/weeklypatientvisits_bereaved.cfm:3) at cfweeklypatientvisits_bereaved2ecfm309418466.runPage(/var/www-vhosts/palcare /teomanga/patient/weeklypatientvisits_bereaved.cfm:1) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:231) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:416) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:381) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48) at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40) at coldfusion.filter.PathFilter.invoke(PathFilter.java:94) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistence Filter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62) at coldfusion.CfmServlet.service(CfmServlet.java:200) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89) at jrun.servlet.FilterChain.doFilter(FilterChain.java:86) at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletF ilter.java:42) at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at jrun.servlet.FilterChain.service(FilterChain.java:101) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java: 320) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428 ) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:26 6) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) I thought perhaps it might have been a query timeout. But we don't use the timeout attribute in any of our SQL. And we use PostgreSQL - and that DSN settings do not have a query timeout setting in CFAdmin for the PostgreSQL driver / datasource. We are bit stuck with this - So I thought I had better ask for some help. Gavin. -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:cfaussie%[email protected]> . For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.com cf.Objective(ANZ) - Nov 17, 18 - Melbourne Australia http://www.cfobjective.com.au Hands-on ColdFusion ORM Training www.ColdFusionOrmTraining.com -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
