答案 0 :(得分：49)
如果您使用的是.Net客户端，那么您可能没有设置
//This says how many outgoing connection you can make to a single endpoint. Default Value is 2
System.Net.ServicePointManager.DefaultConnectionLimit = 200;
这是原始问题和答案WCF Service Throttling
更新：
此配置进入.Net客户端应用程序可能在启动时或在开始测试之前。
此外，你可以在app.config文件中使用它，如下面的
<system.net>
<connectionManagement>
<add maxconnection = "200" address ="*" />
</connectionManagement>
</system.net>
答案 1 :(得分：3)
如果您还没有尝试过 - 将您的服务器端WCF操作封装在try / finally块中，并添加日志记录以确保它们实际返回。
如果那些显示操作正在完成，那么我的下一步将是进入较低级别，并查看实际的传输层。
Wireshark或其他类似的数据包捕获工具在这一点上非常有用。我假设它在标准端口80上运行HTTP。
在客户端上运行Wireshark。在开始捕获的选项中，将捕获过滤器设置为tcp http and host service.example.com - 这将减少不相关的流量。
如果可以，请修改您的客户端以通知您呼叫的确切开始时间以及超时发生的时间。或者只是密切监视它。
当您收到错误消息时，您可以浏览Wireshark日志以查找呼叫的开始。右键单击客户端调出的第一个数据包（应该是GET /service.svc或POST /service.svc）并选择Follow TCP Stream。
Wireshark将解码整个HTTP会话，因此您可以确保WCF实际上发送回响应。
答案 2 :(得分：2)
来自：http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx
为避免此超时错误，我们需要 配置OperationTimeout WCF客户端中代理的属性 码。这种配置是有道理的 新的不同于其他配置 作为发送超时，接收超时等， 这是我在早期讨论过的 文章。设置此操作超时 属性配置，我们必须 将我们的代理转换为IContextChannel 调用之前的WCF客户端应用程序 经营合同方式。
答案 3 :(得分：2)
我遇到了一个非常类似的问题。过去，这与序列化问题有关。如果您仍然遇到此问题，可以验证是否可以正确序列化要返回的对象。具体来说，如果您使用具有关系的Linq-To-Sql对象，则如果将子对象的后引用放在父对象上并将该引用标记为DataMember，则会出现已知的序列化问题。
您可以通过编写一个控制台应用程序来验证序列化，该应用程序使用服务器端的DataContractSerializer以及客户端使用的任何序列化方法对对象进行序列化和反序列化。例如，在我们当前的应用程序中，我们有WPF和Compact Framework客户端。我编写了一个控制台应用程序来验证我可以使用DataContractSerializer进行序列化并使用XmlDesserializer进行反序列化。你可以尝试一下。
此外，如果要返回具有子集合的Linq-To-Sql对象，您可能会尝试确保在服务器端急切地加载它们。有时，由于延迟加载，返回的对象不会被填充，并且可能导致您看到请求多次发送到服务方法的行为。
如果你已经解决了这个问题，我很想听听，因为我也坚持了。我已经证实我的问题不是序列化所以我不知所措。
更新：我不确定它是否会对您有所帮助，但服务跟踪查看器工具在与您的体验非常相似的5天后解决了我的问题。通过设置跟踪然后查看原始XML，我发现导致序列化问题的异常。它与Linq-to-SQL对象有关，偶尔会有比成功序列化更多的子对象。将以下内容添加到web.config文件应该启用跟踪：
<sharedListeners>
<add name="sharedListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\Temp\servicetrace.svclog" />
</sharedListeners>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="sharedListener" />
</listeners>
</source>
</sources>
可以使用服务跟踪查看器工具或仅在IE中打开生成的文件以检查结果。
答案 4 :(得分：2)
您是否在请求之间关闭了与WCF服务的连接？如果你不这样做，你会看到这个确切的超时（最终）。
答案 5 :(得分：2)
我刚刚解决了这个问题。我发现App.config文件中的节点有错误。
<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>
<bindings>
<wsHttpBinding>
<binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
<**security mode="None">**
<transport clientCredentialType="None"></transport>
</security>
</binding>
</wsHttpBinding>
</bindings>
在节点<security>中确认您的配置，属性“mode”值为“None”。如果您的值为“传输”，则会发生错误。
答案 6 :(得分：1)
它可以帮助你在Msdn Blogs中的这个链接：
答案 7 :(得分：0)
您是否尝试使用clientVia查看发送的邮件，使用SOAP toolkit或类似内容？这可以帮助查看错误是来自客户端本身还是来自其他地方。
答案 8 :(得分：0)
我不是WCF专家，但我想知道你是不是在IIS上遇到了DDOS保护。 我从经验中知道，如果您在某个时刻运行从一个客户端到服务器的大量同时连接，服务器会因为怀疑DDOS攻击而停止响应呼叫。 它还会保持连接打开，直到它们超时，以便在攻击中减慢客户端的速度。
来自不同机器/ IP的多个连接应该不是问题。
此MSDN帖子中有更多信息：
http://msdn.microsoft.com/en-us/library/bb463275.aspx
查看MaxConcurrentSession sproperty。
答案 9 :(得分：0)
您是否检查过WCF跟踪？ WCF倾向于吞下异常，只返回最后一个异常，这是你得到的超时，因为结束点没有返回任何有意义的异常。
答案 10 :(得分：0)
如果要将对象传递回包含枚举类型为enum的属性的客户端，并且枚举没有映射到0的值，您也会收到此错误。{{1} }
答案 11 :(得分：0)
看起来这个异常消息非常通用，并且由于各种原因可以接收。我们在Windows 8.1计算机上部署客户端时遇到了这个问题。我们的WCF客户端在Windows服务内运行，并不断轮询WCF服务。 Windows服务在非管理员用户下运行。通过将clientCredentialType设置为＆＃34; Windows＆＃34;在WCF配置中允许身份验证传递，如下所示：
<security mode="None">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>