Asynchronous Methods in WCF
- On the server side – you can declare a method as being asynchronous in the method’s operation contract as an attribute – but I fail to see how it is at all useful when you can just generate all of the asynchronous methods yourself on the client side. If you are using task based operations on the client side – all of your hard work for making your method asynchronous is completely ignored and thus is made pointless.
- On the client side – you have a choice between generated asynchronous based operations and generated task based operations. If you are using Framework 4.5 or have the opportunity to just upgrade to Framework 4.5 – do so and use Tasks. The older methodology of asynchronous based operations is just painful to work with and feels obsolete in comparison to Tasks (TPL).
- This is my final point, but my most important point and motivator for this article. If you are trying to solve a problem with Timeouts because you have a long running task that you want to kick off via WCF – then using Asynchronous methods WILL NOT HELP YOU AT ALL.
Elaboration of Point 3 – Service Timeout Gotcha!
This request operation sent to net.tcp://localhost/WcfService.svc did not receive a reply within the configured timeout (00:00:10). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
- If possible taking large requests and chunking them into smaller requests. Example: processing 1000 objects in one request vs. process 100 objects in 10 requests.
- Using a method as a one way call, setting and forgetting about it: https://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.isoneway(v=vs.110).aspx
- Making your WCF Service Method call you back via a different service pipeline. This approach could get messy, but let’s say your client calls the server, when the server is finished with the request it can call the client back using a service exposed by the client.
- Putting in a request that immediately returns a tracking ID, then using a different method to check the progress of your request using that tracking ID. In this approach think about buying something from an online retailer. You put in the request and you can track your shipment using a tracking number. The only difference here is instead of the package being delivered to your doorstep you have to go pick it up when it is declared “finished”.