CF Web 服务出现严重的间歇性错误
我们编写和维护的基于 CF Web 服务的 API 遇到了令人难以置信的令人沮丧的情况。我们拥有一个 API 多年，该 API 非常稳定，并且可以与 Ruby、PHP 和 ColdFusion 客户端良好地配合使用。然后今年出现了 .NET 客户端，我们发现由于我们广泛使用结构，我们的 Web 服务无法与静态类型语言互操作。
我们最终意识到我们必须重新编写没有结构的 API，并且我们已经这样做了。它现在使用定标器值、数组和 CFC（转换为 SOAP 复杂类型）。 .NET 客户端很满意，我们用大约 6 种不同的语言编写了概念验证客户端，以确保这次我们能够互操作。
令我们非常沮丧的是，我们的 ColdFusion 7 服务器似乎无法可靠地为新 API 提供服务。重新启动后它会工作大约一天左右，然后客户端开始收到如下错误：
错误：coldfusion.xml.rpc.CFCInitationException [java.lang.ClassNotFoundException : tafkan.remote_api.pfapi.v.trunk.rsp_pf_survey_status_array]
和
java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/pf_unit
重新启动 CF 实例是解决问题的唯一方法离开。重建API投入了大量的时间和金钱，所以每个人都对此束手无策。
我们注意到，CF 实例的 WEB-INF/cfc-sculpts 目录最终似乎为 API 使用的每个 CFC 提供了两个类副本。例如：
-rw-r--r-- Feb 17 09:15 remote_api.pfapi.v.trunk.pf_datum.class
-rw-r--r-- Feb 3 12:20 tafkan.remote_api.pfapi.v.trunk.pf_datum.class
错误似乎来自命名空间或类搜索路径问题，因此我们尝试将所有 CFC 引用切换为完全限定（以映射开头的点符号），而不是仅对当前目录中的 CFC 进行简单引用。这看起来很有希望，但问题在 24 小时内又出现了。
环境：
- ColdFusion 7,0,2,142559，带 hf702-70523，2 实例集群
- Sun Java 1.4.2_13
- Apache 2.0.52
- Centos 4.5 32 位
也许升级这些古老的软件之一会有所帮助？也许只升级 AXIS？
Adobe 支持似乎不是一个选项，因为 CF7 已停产并且处于延长支持状态（而且只持续几天）。
更新：
感谢所有参与本次讨论的人！以下是目前情况的最新情况。
这项服务今天第一次出现故障。其中一个集群实例仍然能够生成 WSDL，而另一个实例则表示：
AXIS error
Sorry, something seems to have gone wrong... here are the details:
Exception - java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/rsp_pf_numeric_array
两个 cfc-骨骼目录都包含一个名为 tafkan.remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class 的文件，并且似乎不包含其他文件我们有时会看到的命名文件（remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class）。自昨天服务器启动以来，cfc-sculpts 中的文件似乎没有被修改。
两个实例的正常运行时间约为 21.5 小时。我在没有 JIT (-Xint) 的情况下运行。
我现在已经重新启动了两个实例。它们现在在 Sun Java 1.4.2_19（而不是 _13）上运行，并且 JIT 已重新启用，因为它显然不会导致此错误，并且如果没有它，速度会显着变慢。我还清除了“保存类文件”复选框。
现在，我们再次等待...
更新 2 问题仍然存在。我不确定此时还可以尝试什么。嗯！
仅供参考，此内容交叉发布于 http://www. houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922
We've got an incredibly frustrating situation with a CF Web Services-based API that we wrote and maintain. We had an API in place for years that was stable and working happily with Ruby, PHP, and ColdFusion clients. Then this year a .NET client came along, and we found that our web service was not interoperable with statically-typed languages due to our extensive use of structs.
We eventually realized we had to re-write the API without structs, and we've done so. It now uses scaler values, arrays, and CFCs (which get translated to SOAP complexTypes). The .NET client is happy, and we wrote proof-of-concept clients in about 6 different languages to ensure that we'd be interoperable this time around.
To our great dismay, it appears that our ColdFusion 7 servers can't serve the new API reliably. It works for about a day or so after restarting, then the clients start getting errors like:
Error: coldfusion.xml.rpc.CFCInvocationException
[java.lang.ClassNotFoundException : tafkan.remote_api.pfapi.v.trunk.rsp_pf_survey_status_array]
and
java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/pf_unit
Restarting the CF instances is the only way to make the problem go away. A lot of time and money was put into rebuilding the API, so everyone is really at wit's end about this.
We've noticed that the WEB-INF/cfc-skeletons directories of our CF instances eventually seem to have two copies of the classes for each of the CFCs used by the API. For example:
-rw-r--r-- Feb 17 09:15 remote_api.pfapi.v.trunk.pf_datum.class
-rw-r--r-- Feb 3 12:20 tafkan.remote_api.pfapi.v.trunk.pf_datum.class
It seems like the errors are coming from a namespace or class search path problem, so we tried switching all CFC references to be fully-qualified (dot notation starting with a mapping) instead of just simple references to CFCs in the current directory. This seemed promising, but the problem came back within 24 hours.
Environment:
- ColdFusion 7,0,2,142559 with hf702-70523, 2-instance cluster
- Sun Java 1.4.2_13
- Apache 2.0.52
- Centos 4.5 32-bit
Maybe upgrading one of these venerable pieces of software would help? Maybe upgrading just AXIS?
Adobe support doesn't seem to be an option, as CF7 is EOL'ed and in extended-extended support (and that just for a few more days).
Update:
Thanks to all who've joined this discussion! Here's an update on where things stand at the moment.
The service just crapped out for the first time today. One of the cluster instances was still able to generate the WSDL, while the other instance said:
AXIS error
Sorry, something seems to have gone wrong... here are the details:
Exception - java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/rsp_pf_numeric_array
Both cfc-skeletons directories contain a file called tafkan.remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class, and did not appear to contain the otherly-named files we've sometimes seen (remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class). The files in cfc-skeletons do not appear to have been modified since the servers were started yesterday.
The uptime on both instances was about 21.5 hours. I was running without JIT (-Xint).
I've now restarted both instances. They're now running on Sun Java 1.4.2_19 (instead of _13), and JIT has been re-enabled as it clearly wasn't causing this error and was things were dramatically slower without it. I've also cleared the "save class files" check boxes.
And now, we wait again...
Update 2
The problem persists. I'm not sure what else to try at this point. Arg!
FYI, this is cross-posted at http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我读过这个帖子和 CFTalk 帖子。我对解决方法的最初想法似乎已经由马克·克鲁格和戴夫·瓦茨提出。我唯一的其他解决方法是捕获错误并使用服务工厂方法刷新 Web 服务存根。 （在 CF8-9 中，有一个 Admin API 方法可以执行此操作，但不确定 CF7）。
研究错误后，我缩小了可能的匹配范围：
http:// /www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:144821
这是一场比赛，但尚未解决
http://blog.coldfusionpowered.com/?p=28
这是一个非常相似的错误，通过“修复所有 CFC 和 CFC 上的案例问题”来解决。调用。
ColdFusion Google Adwords 业务组件错误
通过重写代码并删除 cfcomments 来解决（我怀疑其他因素实际上是解决这里问题的原因）
http://forums.crystaltech.com/index.php?topic=22364.0
我们现在越来越近了。解决方案涉及错误地设置两个文档根
http://qaix.com/coldfusion/313-410-web-service-on-cfmx-6-1-jrun-suddenly-not-working-read.shtml
与错误消息完全匹配。与 CFC 映射到文档根完全匹配。解决方案是只有 1 个映射指向 docroot，即“/”。这可能是解决方案。在 MX 6/6.1 甚至 MX 7 中，“/”有一个指向 docroot 的默认映射。如果您有另一个指向 docroot 的映射，那么我可以看到这个问题是如何出现的。检查物理路径的映射并尝试此处的解决方案，仅使用“/”映射。
I've read this thread, and the CFTalk thread. My initial thoughts about workarounds appear to have been already suggested by Mark Kruger and Dave Watts. The only other workaround idea I had was to catch the error and refresh the webservice stub using the Service Factory methods. (In CF8-9 there is a Admin API method to do this, not sure about CF7).
Researching the error I narrowed down possible matches to these:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:144821
This was a match but unresolved
http://blog.coldfusionpowered.com/?p=28
This was a very similar error, resolved by "fixing case issues" on all CFCs & invocations.
ColdFusion Google Adwords Business Component Error
Resolved by rewriting code and removing cfcomments (I suspect that other factors were actually responsible for solving it here)
http://forums.crystaltech.com/index.php?topic=22364.0
We're getting closer now. Resolution involved mistakenly having two document roots
http://qaix.com/coldfusion/313-410-web-service-on-cfmx-6-1-jrun-suddenly-not-working-read.shtml
Exact match for error message. Exact match for having CFC mapping to doc root. Resolution was to have only 1 mapping pointing to docroot, just "/". This could be the solution. In MX 6/6.1 and maybe 7, there was a default mapping for "/" pointing to docroot. If you have another mapping pointing to docroot, then I can see how this problem might arise. Check the physical paths for mappings and try the solution here, to use only the "/" mapping.
外部客户端如何与您的网络服务交互？我想只是通过 WSDL 吗？
是否有可能某些客户端应用程序、单元测试...某些东西...有错误的 URL...您的 WSDL 文件的 URL 中包含“tafkan”？
如果我正在研究这个问题，我首先考虑的可能就是找出可能导致该问题的原因。 “tafkan”是您系统中的有效目录吗？ .cfc 文件实际上位于文件系统上的什么位置？如果 CF Admin 中存在这些路径的映射会怎样？人们用来访问您的 Web 服务的 URL 是什么？
我认为，这里的关键是深入 CF 的头脑并询问它“为什么要生成并寻找一个以“tafkan”作为包的类？
How are the external clients interacting with your webservice? Just via the WSDL I presume?
Is it possible that some client app, a unit test... something, anything ... has a wrong URL... has a URL to your WSDL file with the "tafkan" in it?
If I were working on it, probably the first avenue I'd look down would be figuring out what could possibly result in that problem. Is "tafkan" a valid directory in your system? Where do the .cfc files actually live on the file system, what if any mappings are there to these paths in CF Admin, and what are the URLs that people are using to access your webservice?
The key here, I believe, is getting inside CF's head and asking it "why would you generate, and be looking for, a class with "tafkan" as a package?