Googler, wenn Sie einen Heap-Dump mit einem root von coldfusion.runtime.CFDummyComponent haben, lesen Sie weiter.
Marc Esher von MXUnit fame hat genau den gleichen Fehler gefunden ein anderer Kontext . Seine Lösung beinhaltet eine große Schleife über eine Abfrage, die gelöst wird, indem von query="name" nach from="1" to="#name.recordcount#" index="row" gewechselt wird. Ein anderer Ansatz, der funktioniert, ist die Verwendung von <cfthread> in der Schleife:
Dies ist sehr effektiv, wenn Sie in Situationen kommen, in denen Sie innerhalb der Schleife Dinge wie Abfragen und <cfmodule> in <cffunction> ausführen müssen, so dass der belegte Speicher nur für diese Iteration ist.
Ich hoffe, jemand anderes kann bestätigen oder mir sagen, was ich falsch mache. Ich bin in der Lage, eine laufende OOM konsistent zu reproduzieren, indem ich die Datei oom.cfm aufruft (siehe unten). Mit jconsole kann ich sehen, dass die Anfrage Speicher verbraucht und sie nie wieder freigibt, bis sie abgeschlossen ist. Das Problem scheint <cfmodule> innerhalb von <cffunction> aufzurufen. Wenn ich den <cfmodule> -Aufruf auskommentiere, werden während der Ausführung der Anforderung Garbage-Collection-Vorgänge ausgeführt.
ColdFusion-Version : 9,0,1,274733
JVM-Argumente
%Vor%oom.cfm (ruft unten template.cfm auf - Adobe Fehler # 85736 )
%Vor%template.cfm
%Vor%Update # 2 ( cfthread Fall von Elliott Sprehn - Adobe ColdFusion Bug # 83359 )
%Vor%Ich bin noch nicht auf dieses Problem gestoßen, aber hier ist, was ich denke:
Jedes Mal, wenn cfmodule aufgerufen wird, wird ein neuer Speicherbereich dafür erstellt (was, IIRC, der Hauptunterschied zwischen ihm und cfinclude ist). Da Sie das cfmodule innerhalb der Funktion aufrufen, gehört der Speicherbereich cfmodule technisch zum Speicherbereich dieser Funktion. Der Speicher der Funktion ist vor der Speicherbereinigung geschützt, bis die Funktion beendet ist. Ergebnis: Heap füllt und Sie erhalten einen OOM-Fehler.
Ich glaube nicht, dass das Aufrufen eines Speicherlecks korrekt ist, da es sich korrekt verhält, und wenn die Funktion beendet ist, kann der Garbage Collector den Speicher dieses Speichers löschen. Ich kann jedoch sehen, wie es unbequem sein könnte.
Dieses Problem manifestiert sich leider mit vielen Tags. Ich habe das mit cflock in cfthread gesehen. Schreiben Sie eine sehr lange laufende Schleife in einen cfthread, der cflock verwendet, Sie werden schließlich nicht genügend Speicher haben. Es dauert lange, aber es passiert. Ich wette, dass das Aufbewahrungsproblem auch in regulären Anfragen existiert, aber Sie haben normalerweise keine Schleife, die hunderttausende Male mit einem cflock im Inneren läuft, so dass niemand bemerkt.
Ich habe diesen Fehler vor langer Zeit gemeldet, aber er wurde nie behoben: Ссылка
Die beste Lösung für den Moment ist, cfmodule nicht innerhalb einer Schleife wie dieser zu verwenden. Benutzerdefinierte Tags waren eigentlich nicht dafür gedacht, in einer einzigen Anfrage 20k Mal aufzurufen. Sie werden stattdessen UDFs verwenden wollen. cfmodule ist sowieso extrem teuer und die Verwendung einer UDF wird merklich schneller.
Hier ist eine Diskussion über eine mögliche Coldfusion Version 9 cfc Speicherverlustproblem: Ссылка
Sehen Sie sich diesen Fehlerbericht an: Ссылка
Ich glaube nicht, dass Adobe einen Fix für Version 9.01 veröffentlicht hat, aber dieses Problem wurde angeblich in Version 10 behoben. Es gibt für die meisten Leute Workarounds (abhängig vom Umfang ihres Problems), die nicht anders sind als hier beschrieben / p>
Tags und Links memory-leaks coldfusion coldfusion-9