WCF service does not time out when close/abort is not used

Question

I have an issue with a WCF service, and have written a test Windows application to test it with. The application runs multiple threads  using the BackgroundWorker class, which perform various calls to the WCF service. I am also running perfmon to monitor the Active Requests of the W3SVC_W3WP object.

What I have found is, if I run the program with, for example, 10 threads, and allow it to complete cleanly, the number of Active Requests rises to 10 on opening and falls to zero when the connections are closed, whether I use the Client.Abort() or Client.Close() functions. This is as expected.

If I terminate the test app (by clicking the x in the top-right), the Close() or Abort() function is never executed (fair enough, in the actual app the code may be being terminated suddenly in a similar way). In Perfmon I can see that the Active Requests level remains at 10, seemingly forever, until I do an iisreset.

The result is that if I run it with 60 threads, kill the app, then kick off another 60, the second lot never run because all of the connections are still used up.

Why is this? Is there no timeout that closes these connections after a certain amount of time? My understanding is that the receiveTimeout or inactivityTimeout should kick in and kill these connections. I've set both of these to 30 seconds, but this never seems to happen.

Any help would be gratefully received!

Steve

 

Answer 1

What is the binding that you are using? How are you managing the proxy? Do you use the pattern of, create a proxy, invoke a method, close the proxy? Is the service configured for a PerSession or PerCall?

Based on your follow up response, we might be able to comment further...

Answer 2

I'm using wsHttpBinding. I've referenced the WCF service from the client using the default Service Reference stuff, which gives me a SharepointServiceClient object. In normal use I initialise the SharepointServiceClient object, call a method, then close the proxy using SharepointServiceClient.Close(), or in the case of an exception, SharePointServiceClient.Abort(). However, I am testing the case where there is an abnormal program termination and the Close() or Abort() methods are never run. In this case I would expect that the connection would time out, because I have set up the following binding:

        <binding name="ProFileBinding" receiveTimeout="00:00:30" sendTimeout="05:00:00" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
          <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
          <reliableSession ordered="true" inactivityTimeout="00:00:30" />
          <security>
            <transport />
          </security>
        </binding>

 

However, the connections appear to remain open.

Answer 3

Hello, closing WCF connections does not necessary mean closing IIS connections. I don't know how IIS handles idel connections. But according to http://learn.iis.net/page.aspx/205/dynamicidlethreshold/, the default timeout is 20 minutes. Have you waited for 20 minutes? You can ask IIS questions on http://forums.iis.net/.

---

Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
Windows Azure Technical Forum Support Team Blog

Answer 4

Is this not to do with recycling the application pool though? The web service is being hit pretty much constantly throughout the day. The problem is that when a fault is returned and the connection is aborted, or the web site that calls the web service breaks and neither the abort nor the close are called, an open connection seems to be held open for hours. This may be to do with one of the timeouts, but which one?

Answer 5

This issue was to do with timeouts, I believe the inactivitytimeout was the relevant one in this case. Remarked as answer