|
Async RPC and timeouts |
Post Reply 
|
| Author |
 Share Topic Printable Version Delicious Digg Facebook Furl Google Boomarks Google Buzz MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search  Topic Options
|
Customer 
Senior Member 
User Submitted Questions to Support Joined: 30-May-2007 Location: United States Posts: 260 |
 Post Options
 Quote Reply
 Topic: Async RPC and timeoutsPosted: 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?
|
|
 |
|
|
IdeaBlade
Moderator Group 
Joined: 30-May-2007 Location: United States Posts: 353 |
Post Options
Quote Reply
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). |
|
|
|
|
IdeaBlade
Moderator Group
Joined: 30-May-2007 Location: United States Posts: 353 |
Post Options
Quote Reply
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.
|
|
|
|
|
Post Reply
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |