Net Remoting Timeout

[Sagaert Johan]

Hi

I tried to get around the problem on an un-available remoting server bij
using the async methods (BeginInvoke) but noticed that this call is
blocking if the remote server is not available. the the client throws an
Exception after over 48 seconds, way to long .
The async method seems to be only async when the remote operation takes a
lot of time to execute.


Is there a way to shorten this(connection ) timeout ?

So far i solved by first pinging the remote first, but is no tight solution
since ping only gives me info if the remote pc exists on the network.

Johan

 

[Goran Sliskovic]

Hi

I tried to get around the problem on an un-available remoting server bij
using the async methods (BeginInvoke) but noticed that this call is
blocking if the remote server is not available. the the client throws an
Exception after over 48 seconds, way to long .
The async method seems to be only async when the remote operation takes a
lot of time to execute.


Is there a way to shorten this(connection ) timeout ?

So far i solved by first pinging the remote first, but is no tight solution
since ping only gives me info if the remote pc exists on the network.

Johan

Hi,
As far as I know, there is no way to control timeout in fw 1.1 (only on http
channel, not on tcp). Maybe in 2.0 there is an option, I'm not sure.

That timeout comes from TCP timeout on connect, which is typically around
minute. To make things worse, remoting uses lazy connect, which means you
can expect same timeout on every access of remote object (there is no built
in way to check for connection status). You may handle it yourself, but it's
pain in the ..., since you have to wrap every method.

Even worst situation can occur, if connection goes done after remote host
has received the request, but before response is sent. Your remote call will
hang infinitly (unless TCP keepalive timer kicks in, which is after few
hours I think by default).

The only think I could think of is to execute remote calls on separate
thread and abort that thread on configurable timeout (which is rather ugly,
should be avoided and lot of coding around).

You could try genuinne channels, they have better connection management (at
least they advertise it) + configurable timeouts. I have not tested it
though.

Regards,
Goran