我们最近发现WCF不支持服务端的超时操作(注意,服务端,而不是客户端)。当客户端在指定时间后断开时,我们的测试表明,对于netNamedPipeBinding,netTcpBinding和basicHttpBinding,我们指定的超时不会导致服务操作在调用后停止。以下是我们尝试的特定绑定配置:
<bindings>
<netNamedPipeBinding>
<binding name="TestServiceBindingConfigurationNamedPipe"
receiveTimeout="00:00:05"
sendTimeout="00:00:05"
closeTimeout="00:00:05"
openTimeout="00:00:05" />
</netNamedPipeBinding>
<netTcpBinding>
<binding name="TestServiceBindingConfigurationTcp"
receiveTimeout="00:00:05"
sendTimeout="00:00:05"
closeTimeout="00:00:05"
openTimeout="00:00:05" />
</netTcpBinding>
<basicHttpBinding>
<binding name="TestServiceBindingConfigurationBasicHttp"
receiveTimeout="00:00:05"
sendTimeout="00:00:05"
closeTimeout="00:00:05"
openTimeout="00:00:05" />
</basicHttpBinding>
</bindings>
我们的测试服务实现如下:
public class TestServiceImpl : ITestService
{
public TestResult TestIt(TestArgs args)
{
var stopwatch = new Stopwatch();
stopwatch.Start();
// this is a contrived example, but it shows that WCF never stops this thread
while (true)
{
Console.WriteLine("{0}> I'm running forever...", stopwatch.Elapsed);
}
return new TestResult {Result = "Args were " + args.Args};
}
}
使用netNamedPipeBinding和netTcpBinding,我们的客户端应用程序将在5秒后超时,但服务将无限期地继续运行。
这带来了我的问题 - 这是一个错误吗?是否有特定原因导致WCF如果运行时间超过预期而不想超时服务?
从我的角度来看,其中一些潜在的负面问题包括:
答案 0 :(得分:9)
如果您的代码运行不正常,那么将其计时可能只会让事情变得更糟。 尽可能修复错误的代码!请参阅Eric Lippert的文章Careful with that axe,了解这些情况。
如果正在开发中,您可能需要尝试设置在服务实施中调用System.Threading.Timer
的{{1}}。但是,请确保在返回之前彻底解除了计时器的禁用 - 由于并发问题的混合,并不拥有服务调用到达的线程,这种方法非常容易出错, serviceCallThread.Abort()
的奇怪行为,以及Eric解释盲目终止在杂草中消失的代码的问题。
答案 1 :(得分:2)
我自己也注意到了这个问题......我想不出有什么理由不将服务端操作超时作为平台的一部分。
答案 2 :(得分:0)
怎么样:
<system.web>
<httpRuntime executionTimeout="inSeconds"/>
</system.web>