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.
环境:
- 带有2个实例的hf702-70523的ColdFusion 7,0,2,142559
- 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已被EOL终止，并且具有扩展支持(仅持续了几天).
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
FYI, this is cross-posted at http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922
推荐答案
我已经阅读了该线程和CFTalk线程. Mark Kruger和Dave Watts已经提出了有关变通办法的最初想法.我唯一的其他解决方法是使用Service Factory方法捕获错误并刷新Webservice存根. (在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 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屋！
