I wish to test and observe timeout behaviours between a WCF client and service host. For receiveTimeout and sendTimeout, it is probably easy to transmit a large byte stream that takes more than a few seconds and set those timeout attributes to ridiculously low values.
However, since there is nothing that can be done beyond the calling of a serviceProxy.Open() or .Close() methods, I am thinking what is a good way to delay the opening and closing of WCF connections, to cross the thresholds of openTimeout and closeTimeout?
Well, if you have exposed your contracts correctly (as interfaces), you can mock an instance of the proxy which throws TimeoutException and pass it to your code for use.
Related
I have a system, that request data from a WCF webservice
it is like so:
WCF1 calls WCF2, WCF2 calls WCF3 and WCF3 do its job and returns response
My problem here is some of the operations takes a long time "about 2 min" to process
So if WCF1 send a request that takes long of time, and then another request from WCF1 that should take a second, it will wait until the first request finishes
i read about the problem, some of users said to use
<ServiceBehavior(ConcurrencyMode:=ConcurrencyMode.Multiple, InstanceContextMode:=InstanceContextMode.PerCall)> _
this doesn't solve the problem 100%
Can u please advice
I do not think those settings will solve your problem.
From the source:
In PerCall instancing, concurrency is not relevant, because each
message is processed by a new InstanceContext and, therefore, never
more than one thread is active in the InstanceContext.
Bottom line, because you are using PerCall activation, there is no point in adding the ConcurrencyMode.Multiple as each incoming request will get its own instance of the service class to handle its request.
You should try to narrow down what is really causing the performance problem. Look at the underlying code that your WCF services are calling.
EDIT
From another SO post.
In terms of behavior: ConcurrencyMode does not matter for a PerCall
service instance.
In terms of performance: A PerCall service that is
ConcurrencyMode.Multiple should be slightly faster because its not
creating and acquiring the (unneeded) thread lock that
ConcurrencyMode.Single is using.
I would like to know what is a proper way to handle timeouts in a WCF service.
I have a service that uses sessions. The client does a Connect, various calls (as the user interacts with the client app) and then, at some point, does a Disconnect. The Disconnect operation performs a clean-up on the server (such as releasing COM objects). However, the client can (abnormally) terminate (for various reasons) without calling Disconnect. After the receiveTimeout expires, the services is aborted. I need to handle this in a way that allows me to proper clean-up the session. How can I do that?
Is there an event I can handle? An interface that I can implement and customize the service with it? I have looked, but did not find something. IErrorHandler does not help with the timeouts.
I have thought of a timer on the service that is reset every time a call is made to the service. When the timer elapses, the client is considered disconnected and the service can clean-up the session. Is this appropriate? (This interval should be always smaller than the receiveTimeout of the binding.)
As per http://msdn.microsoft.com/en-us/library/ff183865.aspx, WCF sessions timeout by default after 10 minutes or whatever the receiveTimeout specifies. If your service class implements IDisposable, I believe the Dispose() call should come in at this time, which would give you a second/last chance to clean up any outstanding resources.
I have a quite large "old" WCF Service with many different methods.
The most of these methods are "normal" so they should answer in less than 10 seconds but there are several methods (8 or 9) that are long processes so they can take a long time to get a response.
The receivetimeout and sendtimeout were set to 00:40:00 to ensure they had time enought to accomplish these processes.
The problem is sometimes we have connection issues and the "normal" methods take a really long time to crash...
They are all in the same service because they use a really big model and they wanted to reuse the model from the service in every call (not having a PersonsService.User and a RobotsService.User... because they are the same class in different services).
The first solution I imagine is to make a different Service with those long processes and set a short timeout to the normal service... but I should have to make a lot of changes because of Model use...
Is there any way to set a different timeout in each call? Or by service method? Should I chunk the Service anyway?
Thanks in advance!!
First of all, the timeout to configure in your case is OperationTimeout, which allows the time limit to wait for the service to reply before timing out. You can modify the operation timeout before making a call from the client side.
To set the OperationTimeout on the channel, you can type case your proxy/channel instance as IContextChannel and set OperationTimeout.
For example:
IClientChannel contextChannel = channel as IClientChannel;
contextChannel.OperationTimeout = TimeSpan.FromMinutes(10);
HTH,
Amit
I'm quite misunderstanding the InstanceContextMode.PerSession behavior.
I know about if we want to connect the client with dedicated session, which mean when a client connect the service a session will hold all its calls till the client close the connection.
So is this scenario what is the PerSession behaviour mean or something else.
and in the Throttling we have the MaxConcurrentSessions .
My question : If we declare the InstanceContextMode with PerCall does is the same mean of session dedicated for each client and how the MaxConcurrentSessions affects the PerCall behaviour .
Per call means that for each call a new instance of the service is created to process the call. So there is no possibility of session state being maintained between calls. I suspect that the throttling setting has no effect in this case.
I have a Windows service that logs speed readings from a radar gun to a database. In addition, I made the service a WCF server. I have a Forms and a CF client that subscribe to the service and get called back whenever there is a reading that satisfies certain criteria.
This works in principle, but after some time the channel times out. It seems that there are some fundamental issues with long-running connections (see
http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx) and a duplex HTTP callback may not be the right solution. Are there any other ways I can realize a publish/subscribe pattern with WCF?
Edit: Even with a 2 hour timeout the channel is eventually compromised. I get this error:
The operation 'SignalSpeedData' could not be completed because the sessionful channel timed out waiting to receive a message. To increase the timeout, either set the receiveTimeout property on the binding in your configuration file, or set the ReceiveTimeout property on the Binding directly.
This happened 15 minutes after the last successful call. I am wondering if instead of keeping the session open, it is possible to re-establish a fresh session for every call.
Reliable messaging will take care of your needs. The channel reestablishes itself if there is a problem. WSDualHTTPBinding provides this for the http binding, and there is also a tcp binding that allows this. If you are on the same computer, named pipe binding will provide this by default.