I'm trying to get a better understanding of what's going on when I use a WCF proxy. I'm having trouble understanding what happens when I close (or don't close) a proxy.
What's going on when I call Close() or Abort() on a WCF proxy? What's the difference?
How does it differ between types of bindings (like, a sessionless BasicHttpBinding vs. something sessionful)?
Why can Close() throw in certain situations and why can it be a blocking operation?
Closing WCF client
A client has an inherited responsibility of gracefully closing the connection. It is always recommended to close a proxy client. If the binding between a client and a service is transport-layer sessionful, then closing a proxy is essential to tear down the connection between both parties. Service has a payload threshold defined for concurrent connections. If the number of concurrent connections goes above this threshold linearly then the overall service performance decreases exponentially. This is why it is crucial to dispose of the connection as soon as possible. Closing the proxy also notifies the service instance that it is no longer in use and may be collected by GC (subject to service instance management). If the client does not close a connection, it is still automatically torn down by WCF timeouts (found in the configuration files).
Aborting WCF client
In the situation where there is a fault in the service-client interaction, the objects on both ends are potentially totally broken. Thus using a proxy after the exception is not advised. Given the WCF binding use transport sessions, the client after a fault would not even be able to close it (if there was no transport layer session then the client could use or close the proxy, but this is not recommended as the configuration of sessions could change). So after a fault has happened the only safe operation is to abort a proxy.
Close is a synchronous operation, it can throw if the transport session has been damaged by a fault and it is a blocking operation until a confirmatory response from service is received (true for some bindings).
Related
I am using WCF with NetTcp binding and castle windsor as dependency injection at client side.
I am recieving Socket exceptions at client side sometimes, not always. Tried with different config setting but no luck. exceptions occruence are completely random.
few error messages:
An existing connection was forcibly closed by the remote host
System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Security.SecuritySessionClientSettings`1+ClientSecurityDuplexSessionChannel[System.ServiceModel.Channels.IDuplexSessionChannel], cannot be used for communication because it is in the Faulted state.
Error loading CubeDrillThroughAttributeSets cache: System.ServiceModel.ProtocolException: This channel can no longer be used to send messages as the output session was auto-closed due to a server-initiated shutdown. Either disable auto-close by setting the DispatchRuntime.AutomaticInputSessionShutdown to false, or consider modifying the shutdown protocol with the remote server.
Error loading Locations cache: System.ServiceModel.CommunicationObjectAbortedException: The communication object, System.ServiceModel.Security.SecuritySessionClientSettings`1+ClientSecurityDuplexSessionChannel[System.ServiceModel.Channels.IDuplexSessionChannel], cannot be used for communication because it has been Aborted.
WCF service is configured with PerCall instance mode.
At the client side, I am using dependency injection to inject WCF service proxy (proxy is created using channel factory).
I am not explicitly opening/closing connection with WCF service and leaving this to DI.
already tried using google. my questions are...
using DI for proxy management is good?
How the life time of proxy will be managed.
These proxies are injected in construtor when user select to load some screens in UI app. Can these proxy be timedout as per defined in client app.config file if user just open some screen and not doing anything. if yes, then what is the good way for not to timedout.
are these proxy using WCF connection pooling feature.
Thanks in advance.
I have a duplex WCF service with sessions enabled, and I'm trying avoid fault state exceptions on the client.
I found several discussions arround this topic, but all I have found suggest to recreate the client proxy or channel. Non is focus in duplex services with session enabled.
My problem with that approach is that there is one session per client in the server, and each client has only one instance of the service proxy (singleton service proxy). Because it is duplex, in the client side several objects are listening to events on that service instance (messages sent from the server to the client).
If the service is in faulted state, it can not be used any more. If I discard that instance and create a new one, I'm finding it hard to hook up all the event handlers again to this new instance.
Should I wrap the service and every time an object hooks up for an event, store the handler in a list (so that I can re hook it when service is recreated)? Seems to be lost of code, easy to leak memory...
Is there a way to just restart the client proxy / channel, without discarding all the proxy instance? (I'm using the VS generated proxy)
Any ideas?
Thanks,
MAB
You cannot restart the proxy. The only recovery from faulted state is aborting current instance and recreating the new one. On the client side you must correctly unregister everything dependent on your proxy instance, create new instance and register everything again. This whole operation must happen once you get the exception about channel in faulted state (= when you try to call the service). After recreation you must call the service again.
On the service side the instance is either already dead (that caused the faulted state of the channel) or it will die after session timeout. You must also handle faulted exception when you try to callback on the faulted channel by removing the channel from your known clients and unregistering anything dependent on that channel.
I have a server that is calling back to the client through a callback channel.
The callback contract operations are all marked as IsOneWay. The binding is netTcp.
I sometimes have the scenario where the server is generating more messages than the client can handle (I can simulate this by putting a sleep into the client method).
Eventually I get a "CommunicationException: The socket connection was aborted"
Unfortunately I have no idea what is going on under the hood.
Is the operation queued on the send
or receive side, or both?
Can I monitor these queues?
What causes the timeout?
Does WCF have threads that constantly write/read to the socket?
Does WCF on the receive side eventually stop reading from the socket hence the timeout?
To get more info on whats going on , try to turn on WCF tracing , and using the trace viewer to look at the output. here`s how to turn on tracing, and use the MS trace view utility SvcTraceViewer.exe
in a more direct answer to the question - WCF has a default incomming queue of 10 concurrent sessions, so i'm geussing that this is what you are experiencing when the server stresses the client. it`s possible to configure a larger value though, using the maxConcurrentSessions behaviur parameter.
We have a service which is hosted as a Windows service. netTcpBinding with message security type without reliable session.
On the client side we have a proxy collection cached in a list as channel creation and dispose is costly operations. My client is connecting to server and getting the data from server.
Now if I stop the server, then the CPU jumps up. The worker thread which consumes CPU is for the code execution of
void System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, NativeOverlapped *)
When i dispose all the proxies the client application CPU consumption becomes none. I need to know how we can fix up this issue on the WCF.
One question is why are you having collection of proxy's on client for single wcf service. Say you have 20 proxies and WCF Service instancing is per-session then it will create 20 instances of service on your server each having memory allocated to it. If you are having per-call (which is default) then you will have even more instances. Instead of having list of proxies cant you reuse one proxy.
I suppose when you are stopping service, cpu has to clean(garbage collect) too many instances of service in short time hence it jumps.
Unless you do not close proxies their respective instances on server wont be released.Try making instancing Singleton.
I like using WCF callbacks when I can because to me it is better than the client having to poll the server and its more real time than polling. The question I have is when I subscribe to a WCF service event is there any kind of heart beat that keeps the connection alive between the client and the server. I starting to think that there is not because when the server goes away the subscription is lost and the client does not throw an exception (could be the exception is be swallowed by the WCF runtime). Same is true for the server, when the client goes away and the server attempts to invoke the callback and exception is throw. Any thoughts?
Thanks
There is a good short description of the Duplex contract (WCF callbacks) in this link. The duplex contract is basically two one-way channels and there is no implied message correlation. You are right, there are no "heartbeat" messages are involved, only the normal wsHTTP handshaking traffic occurs when making a duplex call.
I fired up the HTTP traffic sniffer called Fiddler2 (an unsupported Microsoft tool) to verify the session traffic. Didn't see any under-the-hood HTTP "heartbeat" communication occurring during and after the service calls. I left the client running for a good while. Good question, it got me digging a bit.
I went ahead and created a recurring heartbeat to the subscribed clients (basically a call to a function they're hosting).
I've run this for hours and it works, this helps ensure the connection.