I get a lot of questions about Outlook's infamous RPC Canceller.  I'm sure you've seen this at some point (if you've used Outlook 2002 or 2003 with Exchange server).  The RPC Canceller is the feature that gives you that fun little dialog: "Outlook is retrieving data from the Microsoft Exchange Server <Server name>. You can cancel the request or minimize this message to the Windows taskbar until Outlook closes the message automatically."  You can read all about it here.

So this gets MAPI developers thinking: maybe this can be used to make my app better.  We all know EMSMDB32's biggest weakness is the "server-down" scenario.  (By "server-down," I refer to any scenario where the client can't connect to the Exchange server).  MAPI can experience some pretty long delays (15-20 minutes!) before timing out with an error.  So it's understandable that MAPI devs are looking for anything that might alleviate this pain!

You get this feature if you're using Outlook 2002 or later's MAPI.  However, if you're using Exchange's MAPI, then this feature isn't available.  And while at first thought it might seem like a good idea for Exchange to "borrow" this functionality from Outlook, a closer examination doesn't support it.

How Does It Work?

The basic architecture of the RPC Canceller involves a single "canceller thread," and a small pool (3-4) "worker threads."  The "canceller thread" works as the manager for the whole RPC Canceller process.
 
When MAPI calls are made by a client, these are handled by the "canceller thread."  The canceller chooses an available idle "worker thread."  The actual RPC call to the Exchange server is made on this worker thread.  The canceller then monitors that thread's progress and if the RPC call does not return within a certain time, it will present the canceller dialog to the user.
 
If the user chooses to cancel the RPC, then we do not actually cancel the RPC.  Due to the nature of RPC (Remote Procedure Call) and the way EMSMDB uses it, it is not possible to actually cancel an EMSMDB RPC call.  Instead, we simply stop waiting for the worker thread to return!  That thread is still out there waiting for the RPC call to return, and any critical sections owned by that thread will remain locked until the thread actually returns!  Any other threads that are waiting for that critical section will continue to wait.

This is a crucial point.  The RPC Canceller's purpose is to improve perceived performance, not actual performance!  Older versions of Outlook's MAPI made it's RPC calls on the main thread, so if an RPC call took a long time, the Outlook UI would become nonresponsive until the call timed out or returned.  The RPC Canceller allows the UI to remain responsive even in the delayed RPC response scenario.

That's fine for a single-user experience, but wouldn't be very scalable for server-type applications.  Also keep in mind that we disable RPC Canceller when MAPI is run in a service!

So, given the major potential impact to the MAPI subsystem if this feature were ported, and the minimal benefit, don't expect to see this feature in Exchange's MAPI any time in the foreseeable future. ;-)