wcf服务中的线程已中止异常
我有一个WCF服务(内置在.NET框架3.5中)托管在IIS6.0上。
代码流程如下所示
- Client (另一种
服务)调用WCF服务
- WCF服务调用一个线程在后台进行处理，并在完成所有处理后响应被调用的web后台线程，回调该线程。这个调用基本上是一个HTTPs请求，因为客户端是一个web服务。
我正在对我的WCF服务进行负载测试，以定义阈值。观察结果如下：
在1分钟内对WCF服务进行了大约3次1024次请求的迭代，成功通过。完成每次迭代所需的时间大约为25-30分钟。然而，从第四次迭代中可以看到批量失败。大约50%的请求失败，出现以下异常。
异常-线程正被中止。
堆栈跟踪
21_10_2016_09_30_52,9:30:52 AM,Information,Thread name- apSwTTbLTETfwT3y Stack trace in ProcessTestConversion method - at System.Threading.WaitHandle.WaitOneNative(SafeHandle waitableSafeHandle, UInt32 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.InternalWaitOne(SafeHandle waitableSafeHandle, Int64 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext)
at System.Net.LazyAsyncResult.WaitForCompletion(Boolean snap)
at System.Net.Connection.SubmitRequest(HttpWebRequest request, Boolean forcedsubmit)
at System.Net.ServicePoint.SubmitRequest(HttpWebRequest request, String connName)
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
.
.(My function calls stack trace)
.
.我试图解决这个问题的更改如下：
<behavior>
<serviceThrottling maxConcurrentCalls="2000"
maxConcurrentInstances ="2400"
maxConcurrentSessions ="400"/>
</behavior>在web.config中
<system.web>
<compilation debug="false" />
<httpRuntime executionTimeout="1800"/>
</system.web>在web.config中
<system.net>
<connectionManagement>
<add address = "*" maxconnection = "100" />
</connectionManagement>
</system.net>在web.config中
ServicePointManager.DefaultConnectionLimit = 100; (Change in code)我已经按照StackOverflow上许多人的建议，将应用程序池的IdleTimeout属性设置为0。
在任何地方使用这些小溪，我都会在所有的地方进行处理。所以所有的小溪都关闭了。
有人能告诉我是谁在中止线程吗?为什么?有什么方法或工具可以追踪线程中止启动的原因吗？
回答 2
Stack Overflow用户
发布于 2016-10-31 23:40:39
我遇到过这个问题，归根结底是不正确地使用了client类。
当客户端类被实例化时，它不会释放回资源，从而导致吞吐量降低。一个非常无用的异常“线程正被中止”将会发生。通过创建一个帮助器类解决了这个问题，这个帮助器类generic实际上创建了一个客户端对象，然后正确地实现了构造函数和dispose方法。
一些IIS异常对问题的实际原因并不是很有帮助，也不是很真实，但要弄清楚为解决我的问题所做的事情，需要查看IIS日志。特别是"Failed Request Tracing Rules“
希望这能有所帮助，我能理解你的挫败感这是一个令人头疼的问题。
Stack Overflow用户
发布于 2016-11-01 22:23:18
我以前也做过同样的事情。解决方案是通过实现Dispose方法，在其作用域结束后释放资源/客户端。
存在问题的原因是，在使用类型化客户端时自动清理资源的C# using语句不成功，并且抛出的任何异常都被隐式dispose屏蔽，隐式dispose会吞噬实际的异常并抛出一些其他异常，如超时或其他异常。
Dispose "using“语句会导致对C# ()的调用。这与Close()相同，当发生网络错误时可能会抛出异常。因为对Dispose()的调用隐式地发生在"using“代码块的结束括号处，所以编写代码和读取代码的人很可能都不会注意到这种异常来源。这是应用程序错误的潜在来源。(来自MSDN)
您应该释放资源，如：
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}通过这种方式，您不仅可以找到实际的异常来源，而且还可以在发生某些执行时释放资源。
其他替代解决方案也可以实现Dispose，例如：
/// <summary>
/// Calculator Client
/// </summary>
public partial class CalculatorClient : IDisposable
{
#region IDisposable implementation
/// <summary>
/// IDisposable.Dispose implementation, calls Dispose(true).
/// </summary>
void IDisposable.Dispose()
{
Dispose(true);
}
/// <summary>
/// Dispose worker method. Handles graceful shutdown of the
/// client even if it is an faulted state.
/// </summary>
/// <param name="disposing">Are we disposing (alternative
/// is to be finalizing)</param>
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
try
{
if (State != CommunicationState.Faulted)
{
Close();
}
}
finally
{
if (State != CommunicationState.Closed)
{
Abort();
}
}
}
}
/// <summary>
/// Finalizer.
/// </summary>
CalculatorClient()
{
Dispose(false);
}
#endregion
}源：
https://stackoverflow.com/questions/40178498
复制相似问题
腾讯云开发者
