我已经尝试手动更改一些超时值并关闭了IIS保持活动状态。
欢迎任何解决此问题的想法。
谢谢
如果你遇到了这个问题,请仔细阅读!希望你能通过这篇文章省去很多麻烦。先泡杯咖啡吧!
你可能来自传统的编程背景,不涉及SOA相关领域,现在你正在以“传统程序员”的思维方式编写SOA服务。以下是我在构建SOA服务过程中学到的4个最重要的课程。
第一条规则
尽你最大的努力不要编写需要很长时间才能完成的服务。我知道这可能非常棘手,但是调用多次较小的操作比执行所有工作然后返回响应的一个长时间服务更可靠。例如,最近我编写了一个处理所有任务的服务。每个任务都存储为IIS站点中的XML文件,并且每个任务都会将数据导出到系统,例如:SharePoint。在高负载期间,随时可能有多达30,000个待处理任务。在过去的两个月中,即使深入研究了IIS、AppPools和WCF绑定的超时设置,我仍无法使其100%可靠。偶尔我会收到“线程被中止”的消息,而没有任何原因或解释。我耗尽了所有在线知识库,似乎没有人更聪明。最终,在无法修复问题或以可靠的方式重现它们之后,我选择进行完全重写。我将代码更改为每次只处理一个任务,而不是处理所有任务。
这意味着实际上需要调用1个Web服务30,000次,而不是只调用一次,但从性能上看,大致相同。每次调用都会快速响应并且做的工作量少了很多。这有另一个好处,我可以为客户端的每个操作提供即时反馈。在长时间调用中,您最终会一次性收到全部响应。规则2 不要仅仅因为认为WCF 3是更好的技术就将现有的ASMX web服务升级到WCF 3。WCF 3过于架构,不易使用和部署。如果您必须使用WCF,请尽力等待.NET 4框架的版本发布,它似乎已经进行了改进。还有一件事情你会错过,那就是WCF没有测试表单,所以你不能快速启动Web浏览器来测试你的服务。如果你和我一样——“保持简单”——那么WCF 3.5会让你感到沮丧。
规则3 IIS6可能会出现问题,如果可能尽量避免在IIS6上托管您的服务,如果您需要可靠的服务。我并不是说在IIS6中实现可靠性是不可能的,但这需要大量的工作和大量的测试。如果您处理的是关键服务,请尽量避免使用2001年开发的产品。
规则4 不要低估创建可靠SOA服务所需的开发和测试工作。老实说,我只能说这是一个巨大的任务。
我想提一下,当使用用户帐户调用某些函数时,SharePoint会抛出此错误。这些函数需要使用SPSecurity.RunWithElevatedPrivileges
运行。
搜索“wcf sharepoint Thread was being aborted”时,将显示此答案,因此希望对某些人有用,因为“线程被中止”在权限问题上并不是SharePoint抛出的非常有用的信息。