WCF Connections exceeding max connections when using Asynchronous pattern

I ha开发者_运维百科ve a simple WCF service that i'm communicating with Asynchronously.

The thing i don't like is when calling the EndServiceMethod(IASyncResult)

if i forget to call the Close() method, the service will actually leave the connection open and then all remaining connections will fail after the wcf reaches it's max concurrent connections count with timeout exceptions.

I've tried using the [ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)] attribute to the Service contract, which doesn't appear to have any effect on the state of the connection from the service.

Perhaps I've implemented it incorrectly?

Any ideas or suggestions.

I'm trying to locate a behavior pattern for the WCF that allows the clients to make a request, and then the server to respond to the request and then assume that the connection is finished and can be terminated.

This is actually a tricky problem.

On the one hand if you do not close the connection it will remain open until it times out (1 min), under load you will hit the max connections (default 10).

On the other hand you are calling the services asynchronously, so if you close the connect before the callback is received, the callback will be lost.

There are a few things that you could try:

• increase the max connections
• close the connection in the callback handler
• reduce the length of the timeout

Specifies the throttling mechanism of a Windows Communication Foundation (WCF) service.

http://msdn.microsoft.com/en-us/library/ms731379%28v=VS.90%29.aspx

I don't know if this helps:

You can set the binding so that

• Security is set to none

• Reliable sessions are disabled

      <wsHttpBinding>
          <binding name="MyWsHttpBinding">
              <reliableSession enabled="false"/> 
              <security mode="None" />
          </binding>
      </wsHttpBinding>
  

I've discovered that by doing this I can open an unlimited number of channels and "forget" to close them.

Then you have to ask if that's an acceptable configuration for your circumstances.

I wouldn't use the Asynchronous pattern with WCF. Instead I would just use synchronous calls with normal using blocks to ensure the connection is closed. Then I would wrap the whole mess in a normal Task (.NET 4.0) or ThreadPool work item.

Closing any type of connection when you don't need it anymore is just basic developer responsibility. There is nothing to complain about. Close connection and you will not have this problem. Trying to solve missing Close calls in any other way is nonsense.