为什么没有无限循环的请求被ColdFusion请求超时所杀死? [英] Why doesn't a request with an infinite loop get killed by ColdFusion request timeout?

查看:138
本文介绍了为什么没有无限循环的请求被ColdFusion请求超时所杀死?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

首先,我在CF Admin中设置超时请求(秒)到 20

First, I set Timeout Requests after (seconds) to 20 in CF Admin.

一个具有类似 while(true);

的行的cfm页面将运行超过20秒,

The page will run way past 20 seconds, and the thread is still alive as I wrote this.

下面是使用Server Monitor生成的快照

Below is a snapshot taken with Server Monitor

Thread  jrpp-3 request type - TEMPLATE REQUEST
*Template Path - D:\Projects\infiniteLoop.cfm
*Request Parameters - {}
*Request Method - GET
*Client IP address - 127.0.0.1
*Thread elapsed time - 322659 milliseconds


$ b这是正常吗?这是CF9.0.1。,开发版。
使用JRun的多实例设置。

Is this normal?? This is CF9.0.1., developer edition. Multi-instance setup, with JRun.

停止无限循环的唯一方法是重新启动CF。

The only way to stop the infinite loop is to restart CF.

推荐答案

在ColdFuison中请求超时不符合您的预期。他们提出的方式,你会想象有一个看门狗,它检查你的请求已经运行了多长时间,并在请求超时后或短时间内终止。
实际上似乎发生的是,只有当某些标签运行时CF检查请求的流逝时间是否超过设置的限制。 < cfoutput> 是它检查的标签之一,这就是为什么你经常看到超时超时消息指向cfoutput,即使你知道它不能需要很长时间才能执行。

Request timeouts in ColdFuison don't behave in the way you expect. They way it's presented you'd imagine that there's a watchdog which checks how long your request has been running and kills it on or shortly after the request timeout. What actually appears to happen is that only when certain tags are run does CF check whether the elapsed time of the request is over the set limit. <cfoutput> is one of the tags where it checks, which is why you often see the timeout exceeded message pointing to a cfoutput, even though you know it can't be taking long to execute.

<cfsetting requesttimeout="5" enableCFoutputOnly="no" />

<!--- Looping with a condition <cfloop blamed --->
<cfset request.counter=0 />
<cfloop condition="true">
    <cfset sleep(1000) />
    <cfset request.counter=request.counter+1>

    <cflog file="timeout" text="#request.counter#">

    <cfif request.counter GT 8>
        <cfbreak>
    </cfif>

</cfloop>

<!--- Looping with an index, times out, naming CFLOOP as the offending tag --->
<cfloop index="foo" from="1" to="8">
    <cfset sleep(1000) />
</cfloop>

<!--- Looping with an index, times out, naming CFOUTPUT as the offending tag --->
<cfloop index="foo" from="1" to="8">
    <cfset sleep(1000) />
    <cfoutput>Hello</cfoutput>
</cfloop>


<!--- Same loop, but in script. No timeout warning at all --->
<cfscript>
for(foo=1;foo<=8;foo++){
    sleep(1000);
}
</cfscript>

<!--- Same loop, now with WriteOutput() called. Still no timeout --->
<cfscript>
for(foo=1;foo<=8;foo++){
    sleep(1000);
    writeoutput("tick...");
}
</cfscript>

上面的代码显示了requesttimeout的一些奇怪行为。正如Mark Kruger指出的,对外部资源的任何调用都意味着没有检查超时,我的猜测,大块的脚本只是执行你自己的逻辑也不会被检查,留下下一个输出语句被责备。

The code above shows some of the odd behaviour of the requesttimeout. As Mark Kruger pointed out, any call to an external resource will mean no checking for timeout, and its my guess that large blocks of script which are just executing your own logic will also not be checked, leaving the next output statement to be blamed.

如果你需要跟踪代码滞后和超时消息指向错误的地方,我将使用日志记录或jstack从服务器抓取堆栈跟踪而长期运行的代码正在运行。抓取几个相隔几秒的堆栈跟踪,然后通过 Samurai 运行日志文件找到代码正在做什么。

If you need to trace where code is lagging and the timeout messages are pointing to the wrong place, I'd either use logging or jstack to grab stack traces from the server whilst the long-running code is running. Grab a few stack traces a few seconds apart, then run the log file through Samurai to find what the code is doing.

这篇关于为什么没有无限循环的请求被ColdFusion请求超时所杀死?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆