tags:

views:

102

answers:

4

I have 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.

+2  A: 

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
Shiraz Bhaiji
i've been closing it in the callback handler and that seems to work. i guess i was just hoping for a more elegant solution that lets this work happen on the server side.
Beta033
That is actually the best solution. Depending on your code you may be able to count the number of callback handlers and the number of times you have called close and see if they match.
Shiraz Bhaiji
Except for i'm going to have many clients each with possibly with multiple connections. how do public wcf services do this? i can't imagine they expect their clients to always be good about closing the connections when they're done.
Beta033
@Beta033, a public service would have a high max connections and a low timeout.
Shiraz Bhaiji
A: 

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.

Andrew Shepherd
A: 

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.

Ladislav Mrnka
i think you're missing the point. the point was to allow the server to handle this and not force the client to maintain it. that way, catastrophic comm failures would not leave the connection open on the server and take up a slot.
Beta033
No I'm not. Async calls does not replace needs for closing connection. Btw. you mentioned PerCall instancing doesn't work for you. Which binding are you using? PerCall instancing works only with binding which doesn't use transport, reliable or security session.
Ladislav Mrnka
A: 

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.

Jonathan Allen
I'm starting to become convinced that using sync wcf calls wrapped in a worker thread is going to be the way to simulate async communication. thanks.
Beta033