I have a WCF service (built in .NET framework 3.5) hosted on IIS 6.0.
The flow of the code is as follows
I am load testing my WCF service to define the thresholds. The observation is as follows:
Around 3 iterations of 1024 requests made to WCF service within 1 minute pass successfully. Time taken to complete each iteration is around 25-30 mins. However from 4th iteration bulk failures are seen. Around 50% of the requests fail with the below exception.
Exception-Thread was being aborted.
Stack trace
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)
.
.
The changes I tried to solve this problems are as follows:
<behavior>
<serviceThrottling maxConcurrentCalls="2000"
maxConcurrentInstances ="2400"
maxConcurrentSessions ="400"/>
</behavior>
in web.config
<system.web>
<compilation debug="false" />
<httpRuntime executionTimeout="1800"/>
</system.web>
in web.config
<system.net>
<connectionManagement>
<add address = "*" maxconnection = "100" />
</connectionManagement>
</system.net>
in web.config
ServicePointManager.DefaultConnectionLimit = 100; (Change in code)
I have set the IdleTimeout property of the App pool to 0 as suggested by many people on StackOverflow.
Where ever the streams are used I have dispose at all the places. So all the streams are closed.
Can any one tell me who is aborting the threads and why and are there any means or tool to trace the cause for thread abort initiation?
I have come across this issue and it was down to an improper use of the client class.
What was happening is when a client class has been instantiated it would not release the resources back causing a reduction in throughput. A very unhelpful exception "Thread was being aborted" would occur. This was resolved by creating a helper class that generically created a client object and then implemented the constructor and dispose method correctly.
Some IIS exceptions aren't very helpful or true to the actual cause of the problem but to get to bottom of what was done to resolve my issue was to look at the IIS logs. Specifically "Failed Request Tracing Rules"
Hopefully this will help, I can understand your frustration it was a headache to resolve.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With