CF Web 服务出现严重的间歇性错误 [英] Serious, intermittent errors with CF Web Service
问题描述
对于我们编写和维护的基于 CF Web 服务的 API，我们遇到了非常令人沮丧的情况.多年来，我们有一个稳定的 API，可以与 Ruby、PHP 和 ColdFusion 客户端愉快地工作.然后今年出现了一个 .NET 客户端，我们发现由于我们大量使用结构，我们的 Web 服务无法与静态类型语言互操作.
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.
我们最终意识到我们必须在没有结构的情况下重新编写 API，而且我们已经这样做了.它现在使用缩放器值、数组和 CFC(被转换为 SOAP complexTypes)..NET 客户端很高兴，我们用大约 6 种不同的语言编写了概念验证客户端，以确保我们这次可以互操作.
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.
令我们非常沮丧的是，我们的 ColdFusion 7 服务器似乎无法可靠地为新 API 提供服务.重新启动后它可以工作大约一天左右，然后客户端开始收到如下错误:
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:
错误:coldfusion.xml.rpc.CFCInvocationException[java.lang.ClassNotFoundException : tafkan.remote_api.pfapi.v.trunk.rsp_pf_survey_status_array]
Error: coldfusion.xml.rpc.CFCInvocationException [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
java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/pf_unit
重新启动 CF 实例是解决问题的唯一方法.大量的时间和金钱都花在了重建 API 上，所以每个人都对此束手无策.
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.
我们注意到，我们的 CF 实例的 WEB-INF/cfc-skeletons 目录最终似乎对于 API 使用的每个 CFC 都有两个类的副本.例如:
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
错误似乎来自命名空间或类搜索路径问题，因此我们尝试将所有 CFC 引用切换为完全限定(以映射开头的点表示法)，而不仅仅是对当前目录中 CFC 的简单引用.这看起来很有希望，但问题在 24 小时内又出现了.
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.
环境:
- ColdFusion 7,0,2,142559 和 hf702-70523，2 实例集群
- Sun Java 1.4.2_13
- Apache 2.0.52
- Centos 4.5 32 位
也许升级这些古老的软件之一会有所帮助?也许只升级 AXIS?
Maybe upgrading one of these venerable pieces of software would help? Maybe upgrading just AXIS?
Adobe 支持似乎不是一种选择，因为 CF7 已停产并处于扩展扩展支持中(仅支持几天).
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).
更新:
感谢所有参与此讨论的人！以下是有关当前情况的最新信息.
Thanks to all who've joined this discussion! Here's an update on where things stand at the moment.
这项服务今天第一次出现问题.一个集群实例仍然能够生成 WSDL，而另一个实例说:
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
两个 cfc-skeletons 目录都包含一个名为 tafkan.remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class 的文件，并且似乎不包含我们有时看到的其他名称的文件 (remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class).自昨天启动服务器以来，cfc-skeletons 中的文件似乎没有被修改过.
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.
两个实例的正常运行时间约为 21.5 小时.我在没有 JIT (-Xint) 的情况下运行.
The uptime on both instances was about 21.5 hours. I was running without JIT (-Xint).
我现在已经重新启动了这两个实例.它们现在运行在 Sun Java 1.4.2_19(而不是 _13)上，并且 JIT 已重新启用，因为它显然不会导致此错误，而且如果没有它，事情会变得非常慢.我还清除了保存类文件"复选框.
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...
更新 2问题仍然存在.我不确定此时还可以尝试什么.啊！
Update 2 The problem persists. I'm not sure what else to try at this point. Arg!
仅供参考，这是在 http:///www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922
推荐答案
我已经阅读了这个线程，以及 CFTalk 线程.Mark Kruger 和 Dave Watts 似乎已经提出了我对解决方法的初步想法.我唯一的其他解决方法是使用服务工厂方法捕获错误并刷新 web 服务存根.(在 CF8-9 中有一个 Admin API 方法可以做到这一点，不确定 CF7).
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这是一场比赛，但尚未解决
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:144821 This was a match but unresolved
http://blog.coldfusionpowered.com/?p=28这是一个非常相似的错误，通过在所有 CFC 上修复案例问题"得到解决.调用.
http://blog.coldfusionpowered.com/?p=28 This was a very similar error, resolved by "fixing case issues" on all CFCs & invocations.
ColdFusion Google Adwords 业务组件错误通过重写代码和删除cfcomments来解决(我怀疑其他因素实际上是在这里解决它的原因)
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我们现在越来越近了.解决方法涉及错误地拥有两个文档根
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错误消息的完全匹配.将 CFC 映射到文档根目录的完全匹配.解决方案是只有 1 个映射指向 docroot，只有/".这可能是解决方案.在 MX 6/6.1 和 7 中，/"有一个默认映射指向 docroot.如果您有另一个指向 docroot 的映射，那么我可以看到这个问题是如何出现的.检查映射的物理路径并在此处尝试解决方案，仅使用/"映射.
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.
这篇关于CF Web 服务出现严重的间歇性错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
