CF Web服务的严重，间歇性问题 [英] Serious, intermittent problem with CF Web Service
问题描述
How，CFers！我们有一个令人难以置信的令人沮丧的情况，我们编写和维护基于CF Web服务的API。我们有一个在多年来的API，它是稳定的，并与Ruby，PHP和ColdFusion客户端愉快地工作。然后今年一个.NET客户端来了，我们发现，由于我们广泛使用结构体，我们的Web服务不能与静态类型语言互操作。
Howdy, CFers! 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，我们这样做了。它现在使用scaler值，数组和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实例是使问题消失的唯一方法。
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.
我们注意到，WEB-INF / cfc-我们的CF实例的框架目录最终似乎对于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。
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 with hf702-70523，2-instance cluster
- Sun Java 1.4.2_13
- Apache 2.0.52
- Centos 4.5 32位
- 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
也许升级其中一个可靠的软件？也许只升级AXIS？
Maybe upgrading one of these venerable pieces of software would help? Maybe upgrading just AXIS?
我们需要帮助！我相信有人在那里有更多的CF / AXIS / SOAP体验比我们，可以帮助我们解决这个问题。 Adobe支持似乎不是一个选项，因为CF7是EOL和扩展支持（只是几天）。我们会支付合适的人好钱，帮助我们明白这一点。如果你是那个人，或认为你可能知道他们是谁，请尽快与我联系！
We need help! I'm sure that there is someone out there with more CF/AXIS/SOAP experience than us that can help us get this problem resolved. 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). We will pay the right person good money to help us figure this out. If you're that person, or think you might know who they are, please contact me ASAP!
感谢您阅读这个巨型帖子！
Leon
Thanks for reading this mega-post! Leon
更新：
加入这个讨论！
这项服务今天第一次出现。其中一个集群实例仍然能够生成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）。
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小时，因此cfc-skeletons中的文件似乎没有被修改。我没有运行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
问题依然存在。我不知道还有什么可以尝试在这一点上。 Arg！
Update 2 The problem persists. I'm not sure what else to try at this point. Arg!
FYI，这是交叉贴在 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提出。我唯一的另一个解决方法的想法是捕获错误和刷新webservice存根使用服务工厂方法。 （在CF8-9中有一个管理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
此是一个非常类似的错误，通过修正案例问题解决所有CFCs&调用。
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)
< a href =http://forums.crystaltech.com/index.php?topic=22364.0 =nofollow noreferrer> 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映射到文档根目录的完全匹配。分辨率只有一个映射指向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屋！
