3

My team runs ColdFusion (v9) on five separate servers. Three of them are on a load balanced router, and the other two are development and test machines.

Several months ago, we began to have issues where certain page/template requests would fail. When I say fail, I mean that the server would return a 500 error. The error, however, did not trigger our ColdFusion exception handling via cftry/cfcatch and cferror.

After examining the HTTP headers, it looked like some sort of jrun error, so I went into the exception log. Here is an example of an error (this one happened this morning):

"Error","jrpp-1","07/30/12","06:30:02",,"(class: cfezReporting2ecfc400556386, method: runPage signature: ()Ljava/lang/Object;) Incompatible object argument for function call The specific sequence of files included or processed is: X:\docs\ezBuilder\index.cfm'' "
java.lang.VerifyError: (class: cfezReporting2ecfc400556386, method: runPage signature: ()Ljava/lang/Object;) Incompatible object argument for function call
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
    at java.lang.Class.getConstructor0(Class.java:2699)
    at java.lang.Class.newInstance0(Class.java:326)
    at java.lang.Class.newInstance(Class.java:308)
    at coldfusion.runtime.TemplateClassLoader.newInstance(TemplateClassLoader.java:552)
    at coldfusion.runtime.TemplateClassLoader.newInstance(TemplateClassLoader.java:523)
    at coldfusion.runtime.TemplateProxyFactory.getCFCInstance(TemplateProxyFactory.java:270)
    at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:173)
    at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:158)
    at coldfusion.runtime.TemplateProxyFactory.resolveName(TemplateProxyFactory.java:148)
    at coldfusion.cfc.ComponentProxyFactory.getProxy(ComponentProxyFactory.java:62)
    at coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:373)
    at cfezBuilder2ecfc293785079$funcCREATE_UVN._factor7(X:\docs\ezBuilder\components\ezBuilder.cfc:376)
    at cfezBuilder2ecfc293785079$funcCREATE_UVN.runFunction(X:\docs\ezBuilder\components\ezBuilder.cfc:327)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:472)
    at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:405)
    at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:368)
    at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:55)
    at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:321)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:517)
    at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2547)
    at coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:460)

Once this error occurred on a template, it would continue to occur, i.e. it was not sporadic and didn't 'fix itself'.

Another interesting tidbit is that this error seemed to occur on all the servers simultaneously on the same file. By simultaneously, I mean by the time we received notice that one is erroring, we test the other servers and find they are also erroring.

Not being able to find help on this particular error detail anywhere, I made a guess that somehow ColdFusion was unable to find a template or class file. I checked each server and the .cfc file was there (plus, the 'template not found' exception has always been different).

So instead, I made a change to the file (ezReporting.cfc in the above example) and copied it to all the servers, and lo and behold, it worked. The change was simply adding and then removing a space - basically forcing the template to recompile, I guess. I did this each time over the next few weeks each time the error occurred. It was always on that .cfc file.

The next time the error happened, about a week later, it was on the exact same file. This time, I cleared the template cache on the server rather than physically change the template. It worked again.

Since then, this same error occurred on several different files - both CFCs and CFM files. I did not notice a pattern in (a) the "age"/last updated date of the files - everything from a day old to over a year, (b) the content of the files - everything from simple blocks to SQL queries to some basic set/looping, or (c) the names of the files.

This morning, it occurred on yet another file, one that I knew worked two days prior on all servers. The CFC file contents had not been touched on any servers since last year. And, when I went to all five servers, the exact same file failed on all of them. When I cleared the template cache, every server started working again.

I'm giving all these boring details because I'm reaching for anything that can help. Perhaps there is some sort of expiration occurring on the file itself, and that would explain why the file expired on all servers right around the same time -- we change it on the development server and then move it out to the test and production servers with a simple copy/paste. But, there doesn't seem to be any rhyme or reason for expiration, because the file in question is of varying ages as noted above.

I tried the Adobe forums to get help on this particular exception/dump, but have not found anyone who has run into the same thing.

Does anyone else have any ideas? This error troubles me because it doesn't trigger our normal exception handling, so we can't do much about it without human intervention. Thanks for any specific guidance.

4

3 に答える 3

2

バーニーがあなたに言うように、壊れたテンプレートキャッシュを経験しているリクレイ。/ cfclassesフォルダー内のファイルをクリアすることは、良い出発点になる可能性があります。次に、ファイルシステムの状態を確認します(デフラグなど)。クラスのロードでファイルI/Oの問題が発生する可能性があります。Webサーバーによって実際に「実行」されているのはこれらのクラスであり、.cfmファイルではありません。

私を困惑させる唯一のことは、エラーが「同時に発生する」ということです。ある種のプリコンパイルプロセスが進行中ですか?すべてのサイトがNASなどで同じ物理コードベースを共有していますか?それは私には奇妙に思える部分です。

于 2012-07-30T17:16:29.977 に答える
1

私は同じ問題を抱えていましたが、残念ながらそれを修正することはできませんでした. 1 つのスペース トリックはまったく同じで、再コンパイルのための小さな変更が毎回修正されました。

于 2012-08-01T03:06:38.370 に答える
0

これと同じ問題を抱えている人のために、最近取り組んだ疑似「解決策」を追加したいと思いました。私がまだ知らない根本的な問題に対処していないので、疑似と言います。ただし、アプリケーションはエラーから回復できます。

つまり、ColdFusion の <cfcatch> は、type="any" であっても、JRE からスローされたエラーをキャッチしません。ただし、この特定のエラーは <cfcatch type="java.lang.VerifyError"> で捕捉できます。

その cfcatch では、管理者関数を使用して、clearComponentCache() および clearTrustedCache() メソッドでテンプレート キャッシュをクリアします。次に、失敗したばかりのコードをコピーするのではなく、<cflocation> を実行して、ユーザーが同じ URL を返して再試行できるようにします。

ユーザーの転送はこの特定のアプリケーションで機能しますが、ajax 呼び出しなどの状況では問題になる可能性があります。ただし、その場合、単純に cfms を再インクルードするか、最初にエラーが発生した CFC を再度呼び出すことができると思います。

これがうまくいくかどうか、または他の誰かがより良い解決策を見つけたかどうかを教えてください。

于 2012-10-01T13:51:37.963 に答える