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

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

问题描述

首先,我在 CF Admin 中将 Timeout Requests after (seconds) 设置为 20.

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

然后我用 while(true);

页面将运行超过 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:ProjectsinfiniteLoop.cfm
*Request Parameters - {}
*Request Method - GET
*Client IP address - 127.0.0.1
*Thread elapsed time - 322659 milliseconds

这正常吗??这是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>

上面的代码显示了请求超时的一些奇怪行为.正如 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天全站免登陆