Async RPC and timeouts

   I wanted to add some additional comments.

The length of time allotted for server response has nothing to do with whether the request is async or not.

"Async" merely means (in this context) that the UI is not blocked during the request. Blocking or not blocking has no bearing on the time it takes to complete a request. There is only so much time for the server to complete its task and get back to the client with the result. I hasten to add that amount of time allotted is the same whether it is a GetEntities or a RPC request: all of these requests go over the same channel.

In sum, GetEntities or RPC, async or sync, there is a finite amount of time for the full round trip of request and response. If that trip exceeds the allotted time, the operation "times out".

The request timeout is configurable ON THE SERVER-SIDE

===

Please note that "Push" is a completely different topic. The time between a client's request and the response can be very long ... and is not governed by the timeout discussed here (except, of course, that the client's request for push service has to complete in time).

===

Most requests (async or not) will complete quickly. There may be a small number of requests that we know will take longer than the standard or default time [see Kim's email on the defaults for both Remoting and WCF and the fact that WCF offers several timeouts].

It would be unwise to set the server default to match the longest possible request. It is probably better to adopt a convention whereby a PM presenting a particular rdbkey extension gets a channel with a long timeout. Most requests use the regular path with the standard timeout. A client that needs to post a long running request would do so through a PM using this "long timeout" extension.