Hi Rocky,
In my SL app, sometimes I have to execute commands which run in a long time (> 60 minutes). I already set closeTimeout, openTimeout, receiveTimeout, sendTimeout to a big value (i.e 12:00:00) in both client and server but I always get a timeout exception after a command exceeds 10 minutes of running. I found the reason resides on IClientChannel.OperationTimeout which is 10 minutes by default. I tried to create my own custom WcfProxy and overrode the GetProxy like below and I see the timeout problem is resolved.
protected override Csla.WcfPortal.WcfPortalClient GetProxy()
{
var proxy = base.GetProxy();
proxy.InnerChannel.OperationTimeout = TimeSpan.FromHours(12);
return proxy;
}
I look into CSLA SL source code and I see you already declared the WcfProxy.TimeoutInMinutes static property but it is private. It is possible if you declare it as a public static property to allow users change timeout value and this timeout value will be also set to IClientChannel.OperationTimeout when CSLA SL creates proxies?
So you are tying up one of your 2 channels for possibly more than 60 minutes?
I'd suggest that you look into using one-way binding on the webservice call (just start and forget) and rather have a "poll" method to check the status. That way no channels is tied up and client will perform much better. .
This seems like a flawed architecture at a basic level.
If you have long-running tasks (things that take minutes, much less hours), you should really look at a model where the client submits the task to a service or app running on the server.
The client can check in periodically (every few seconds or minutes) to see how the task is progressing, but web protocols just aren't designed for (essentially) permanent connections like you are trying to use.
There are various technologies for this, including MSMQ, SQL server queues, Windows services, etc.
So you are tying up one of your 2 channels for possibly more than 60 minutes?
I'd suggest that you look into using one-way binding on the webservice call (just start and forget) and rather have a "poll" method to check the status. That way no channels is tied up and client will perform much better. .
In my app, these commands do not always execute in a long time. They may execute in a short time and they may fail => so I need the server returns the result (SUCCEEDED/FAILED) to the client
Copyright (c) Marimer LLC