DevForce Classic: Async RPC and timeouts

Async RPC and timeouts

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=336
Printed Date: 12-Jun-2026 at 1:26am

Topic: Async RPC and timeouts

Posted By: Customer
Subject: Async RPC and timeouts
Date Posted: 27-Jul-2007 at 9:46am

I understand that "RPC async" can be used as a means to invoke an arbitrary server side method. I've been told that this method can be a long-running process but I never actually thought about how long that could be. Is there a limit to how long the timeout period can be? How is this timeout configured?

Replies:

Posted By: IdeaBlade
Date Posted: 27-Jul-2007 at 9:48am

The default timeout value(s) and how they are set differ between WCF and remoting, but are always set on the communications channel, not per individual request.

With WCF, timeouts are extremely configurable � there are separate timeout settings for send, receive, inactivity, open and close. Generally, the SendTimeout defaults to 1 minute, and the ReceiveTimeout defaults to 10 minutes. Within DevForce, these values can be overridden by configuring communications using an app.config.

With remoting, there�s one timeout value for sending/receiving on the channel, and the value apparently defaults to infinite. The value can also be configured using an app.config file.

Our async RPC implementation (which is not the same as our Push implementation) uses the same communications channel as is used for all other client to PersistenceServer calls. In WCF we open a �channel� to each PersistenceServer (there will be one PS per data source extension).

Posted By: IdeaBlade
Date Posted: 27-Jul-2007 at 9:52am

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.