WCF and SDK and Threads, Oh My!

Since the SDK uses WCF under the covers for communicating with the SDK service, users of the SDK must play nice with it when it comes to thread pool utilization. WCF works a bit differently than it would appear from programmatically using it; namely all the calls are asynchronous and the reply is actually processed on a different thread than the method invocation thread. This poses an interesting problem: what if there are not threads to service the reply? A coworker of mine ran into this issue and needless to say, it stalemated his application. He enqueued a bunch of task execution methods onto the threadpool and all of them woke up and submitted their tasks. The replies could not be processed (and in this particular case, there is actually a separate client-callback method that needs to be processed), so they all appeared to just hang, even though the server showed no signs of the calls being blocked. Well, they weren't; they were just done, but unable to retrieve the reply. Longer story short, don't use all your threads to do remote SDK calls.