WCF stops responding after about 10 or so calls (throttling)

Question

I have a WCF Service and an application with a Service Reference to it, and with the application I have a loop and in each iteration it\'s making a call to a method in this

Answer 1

This can be solved by creating singleton class as interface between web service reference and application. Then it will create only one instance of service reference.

class ServiceInterface
{
     private static ServiceInterface  _instance;
     private ServiceClient _service = new ServiceClient ;
     private ServiceInterface()
     {
       //Prevent accessing default constructor
     }

     public static ServiceInterface GetInstance()
     {

     if(_instance == null)

     {

      _instance = new ServiceInterface();

    }

        return _instance;



 }


   // You can add your functions to access web service here

    Public int PerformTask()
    {
         return _service.PerformTask();
    }
}

Answer 2

Can you configure tracing and run the loop? It may be that the channel is becoming faulted and causing the client to time out.

Answer 3

After pulling my hairs over a much similar problem that was not solved by either Close() or Dispose() I would like to add a simple solution that made my day, namely by increasing the ServicePointManager.DefaultConnectionLimit which is by default 2.

"The DefaultConnectionLimit property sets the default maximum number of concurrent connections that the ServicePointManager object assigns to the ConnectionLimit property when creating ServicePoint objects."

In my case my application successfully connected to my remote service 2 times, on the third attempt it simply did not try to connect to the service. Instead it waited for a while before timing out with the same error message as in the question above. Increasing DefaultConnectionLimit resolved this. To add to the frustration this behavior was somewhat random - in one case of 10 the webservice was invoked successfully multiple (>2) times.

The solution originates and are further discussed these two threads: wcf-timeout-exception-detailed-investigation and wcf-service-throttling. solved my issue.

Answer 4

The default number of allowed concurrent connections is 10.
Most likely your client is not closing the connections.

To increase the number of concurrent calls, you will have to add your behavior to the service configuration, not the client.

Answer 5

A call to clientservice.close() will solve the problem.

Answer 6

I ran into this problem this week and I wasn't able to quite figure out what was going on. I actually did change my call to my service to Dispose() the service client, but it didn't seem to have any effect. Apparently, there was another service call lurking somewhere.

What may be interesting to note is what made me decide that this was not the problem: this limit is not related to the actual number of socket connections to the webservice. When you hit the maxConcurrentSessions limit, there is still only one actual socket connection. I was checking this with netstat, which brought me to the wrong conclusion. So, don't confuse sessions with sockets.

We have interfaces defined for all our WCF services, so I'm planning to adapt this pattern in my code now:

IMyService service = new MyServiceClient();
using (service as IDisposable)
{
    service.MyServiceMethod();
}

What's also interesting, is that the problem did not occur for me when the services (and website) were hosted on IIS. The configuration is (almost) identical, yet I could not reproduce this behavior on that machine. I guess that's a good thing :)

@ John Saunders (about variable assignment in using):

I usually do put the variable assignment in the using statement. But the IMyService that's generated is not implicitly convertible to IDisposable. If you really wanted the assignment in there, I suppose the alternative would be:

IService service;
using ((service = new ServiceClient()) as IDisposable)
{
}

That still leaves the problem of the variable scope being wrong though. The reference to IService service is unusable, but still in scope. So this would be better in that respect:

using (IDisposable serviceDisposable = new ServiceClient())
{
     IService service = (IService)serviceDisposable;
}

That requires me to introduce an extra variable name though. *Meh*