Use thread or asynchronous call to avoid DCOM timeout setting too long
Always ask me to make a long-term setting too long when DCOM can't complete the remote instantiation request or method call. Typical scenes are as follows: The client calls CocreateInstanceex to instantiate an object on the remote machine, but this machine is temporarily offline. On Windows NT 4.0, the activation request will not fail immediately, and the DCOM may take a minute or more to return the failure of HRESULT. DCOM may also take a long time to fail to call the way to call the remote object that has no longer existed or its host has offline. If possible, how should developers avoid these longer timeout settings?
To answer this question, a few words are unclear. DCOM is highly dependent on the underlying network protocol and the RPC subsystem. There is no magical setting to let you limit the duration of the DCOM timeout setting. However, I often use two techniques to avoid longer overtime settings.
In Windows 2000, you can use asynchronous method calls to release the call thread when you are running in the COM channel. (For the introduction of asynchronous methods, please refer to "Windows 2000: Asynchronous Method Calls Eliminate the Wait For Com Clients and Servers Alike" in MSDN Magazine, 2000. If the asynchronous call does not return within a reasonable time, you can use IcancelMethodCalls :: Cancel on the invocation of the initialization call is canceled.
Windows NT 4.0 does not support asynchronous method calls, even in Windows 2000, asynchronous activation requests are not supported. How to solve it? Call the remote object (or instantiate the request for the object) from the background thread. Enable the main thread to block on the event object and specify the timeout set value to reflect the length of time you are willing to wait. When the call is returned, let the background thread set the event. Suppose the main thread uses WaitForsingleObject blocking. When WaitForsingleObject returns, the return value can tell you, return because method calls or activation requests return, or because you specified in the WaitForsingleObject call, the timeout setting expires in the waitforsingleObject call. You cannot unannounced calls in Windows NT 4.0, but at least the main thread can freely perform your own tasks.
The code in Figure 5 demonstrates how the client based on Windows NT 4.0 can call the object from the background thread. In this example, thread a encloses an IFOO interface pointer and starts thread B. Thread B cancels the interface pointer and calls iFoo :: bar. Regardless of the time spent returned to the call, thread A will not block more than 5 seconds because it passes 5,000 (microseconds) in the second parameter of WaitForsingleObject. This is not a good way, but if "no matter what happens in the other end of the line, thread a will not hang", it is important to endure this trouble.
