8

coldfusion.runtime.CFDummyComponentルートが読み取られたヒープダンプがある場合は、Google社員。

2011年2月22日更新

MXUnitで有名なMarcEsherは、まったく同じバグを別のコンテキストで見つけました。query="name"彼の解決策は、からに行くことによって解決されるクエリの大きなループを含みますfrom="1" to="#name.recordcount#" index="row"。動作する別のアプローチは<cfthread>、ループ内をそのように使用することです。

<cfloop ...>
    <cfset threadName = "thread" & createUuid()>
    <cfthread name="#threadName#">
        <!--- do stuff --->
    </cfthread>
    <cfthread action="join" name="#threadName#">
</cfloop>

<cfmodule>これは、クエリのようにループ内や内部で何かを行う必要がある状況に遭遇したときに非常に効果的であり、<cffunction>消費されるメモリはその反復専用です。

古い質問

他の誰かが私が間違っていることを確認または教えてくれることを願っています。ファイルoom.cfm（以下に表示）を呼び出すことで、実行中のOOMを一貫して再現できます。jconsoleを使用すると、リクエストがメモリを消費し、完了するまで解放されないことがわかります。問題は<cfmodule>内部で呼び出しているようです。呼び出し<cffunction>をコメントアウトする<cfmodule>と、リクエストの実行中にガベージコレクションが行われます。

ColdFusionバージョン：9,0,1,274733

JVM引数

java.home=C:/Program Files/Java/jdk1.6.0_18
java.args=-server  -Xms768m -Xmx768m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:+UseParallelGC -Xbatch -Dcoldfusion.rootDir={application.home}/ -Djava.security.policy={application.home}/servers/41ep8/cfusion.ear/cfusion.war/WEB-INF/cfusion/lib/coldfusion.policy -Djava.security.auth.policy={application.home}/servers/41ep8/cfusion.ear/cfusion.war/WEB-INF/cfusion/lib/neo_jaas.policy -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=56033

テストケース

oom.cfm（これは以下のtemplate.cfmを呼び出します-Adobe Bug＃85736）

<cffunction name="fun" output="false" access="public" returntype="any" hint="">
    <cfset var local = structNew()/>
    <!--- comment out cfmodule and no OOM --->
    <cfmodule template="template.cfm">
</cffunction>

<cfset size = 1000 * 200>
<cfloop from="1" to="#size#" index="idx">
    <cfset fun()>
    <cfif NOT idx mod 1000>
        <cflog file="se-err" text="#idx# of #size#">
    </cfif>
</cfloop>

template.cfm

<!--- I am empty! --->

アップデート＃2（ ElliottSprehnのcfthreadケース-AdobeColdFusionBug ＃83359）

<cfthread name="test">  
  <cfloop from="1" to="10000" index="i">      
    <cflog text="This is very bad.">      
    <cflock name="test" timeout="10">      
    </cflock>  
  </cfloop>  
  <!--- Sleep a very long time (10 minutes) --->  
  <cfset sleep(600000)>
</cfthread>
4

3 に答える 3

5

私はこれまでこれに遭遇したことはありませんが、これが起こっていると私が思うことです：

cfmoduleが呼び出されるたびに、新しいメモリスペースが作成されます（これは、IIRCとcfincludeの主な違いです）。関数内でcfmoduleを呼び出しているため、cfmoduleのメモリ空間は技術的にはその関数のメモリ空間に属します。関数のメモリは、関数が完了するまでガベージコレクションから保護されます。結果：ヒープがいっぱいになり、OOMエラーが発生します。

これは正しく動作しているため、これをメモリリークと呼ぶのは正しいとは思いません。関数が完了すると、ガベージコレクタはそのメモリの保留を解除できます。しかし、それがいかに不便であるかはわかります。

于 2011-01-07T19:02:23.050 に答える
3

この問題は、残念ながら多くのタグで発生します。私はこれをcfthread内のcflockで見ました。cflockを使用するcfthreadで非常に長時間実行されるループを作成すると、最終的にメモリが不足します。長い時間がかかりますが、それは起こります。保持の問題は通常のリクエストにも存在するに違いありませんが、通常、cflockが内部にある状態で数十万回実行されるループはないため、誰も気づきません。

私はずっと前にこのバグを報告しましたが、修正されることはありませんでした： http ://www.elliottsprehn.com/cfbugs/bugs/83359

今のところ最善の解決策は、このようなループ内でcfmoduleを使用しないことです。カスタムタグは、実際には1回のリクエストで2万回呼び出すことを目的としていませんでした。代わりにUDFを使用する必要があります。cfmoduleはとにかく非常に高価であり、UDFの使用は著しく高速になります。

于 2011-01-08T10:46:32.820 に答える
0

関連する可能性のあるColdfusionバージョン9のcfcメモリリークの問題についての説明は次のとおりです。http：//forums.adobe.com/thread/1034324？start = 0＆tstart = 0

このバグレポートを参照してください：https ：//bugbase.adobe.com/index.cfm？event = bug＆id = 3124148

アドビがバージョン9.01の修正をリリースしたとは思いませんが、おそらくこの問題はバージョン10で修正されています。これについては、ここで説明したものと同じように、ほとんどの人（問題の範囲によって異なります）に回避策があります。

于 2012-08-02T20:04:16.727 に答える