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.
Related
Can you please tell me a way to check if the client is alive on the host?
I am having problems when the client application shuts down or crashes, it does not tell the host that it is disconnecting and the client is still present in the client list on the host.
Then, any other iteraction with the host, hangs and timesout.
Look at reliable sessions in WCF. In the simplest case you can just add <reliableSession> tag in the binding in configuration file.
Another way is to use duplex contracts. In this case the service implements an incoming contract; the client implements a callback contract.
i used duplex services but when the client unexpectedly closes down due to a shutdown or crash, the host is unusable. I need to restart it.
I googled on this issue and i find that when the client unexpectedly closes, the channel is no more usable.
I would like to know how to handle these ususable channels on the host.
I'm developing a client/server app in which the client calls the WCF service every few seconds. I'm not using IIS - the service runs as a console app (with the intention of installing it as a Windows service on production systems).
I started off using basicHttpBinding, and if I stop the service (to simulate a comms/server failure) the client simply ignores the fact that it can't connect to the service, by handling the EndpointNotFoundException that gets thrown. After restarting the service, the client is able to start calling it again and everything is good.
I've now switched to using netTcpBinding, and this time when I stop the service it takes a little while for its console window to close (presumably due to the way TCP manages the connection, which eventually times out). At this point the client gets a CommunicationException ("the socket connection was aborted"). When I restart the service, the client isn't able to "resume" like it did with basicHttpBinding. Each time it tries to call the service it throws a CommunicationObjectFaultedException ("The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.").
How would I go about building in some kind of resume/recovery behaviour, similar to what I saw with basicHttpBinding?
You cannot reuse the channel as it has faulted. You should cast your client to an ICommunicationObject and call Abort() to clean up.
After that you simply start afresh by creating a new client channel. You may want to do this on a timer if your server is down for a period of time.
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'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).
Suppose you expose a WCF Service from one project and consume it in another project using 'Add Service Reference' (in this case a Framework 3.5 WPF Application).
Will ClientBase perform any kind of connection pooling of the underlying channel when you re-instantiate a ClientBase derived proxy or will you incur the full overhead of establishing the connection with the service every time? I am especially concerned about this since we are using security mode="Message" with wsHttpBinding.
Please take a look at this article which describes best practices on how to cache your client proxies. If you're creating your proxy directly (MyProxy p = new MyProxy(...)), then it seems that you really can't cache the underlying ChannelFactory, which is the expensive part. But if you use ChannelFactory to create your proxy, the ChannelFactory is cached by the proxy at the AppDomain level, and it's based on the parameters you pass to the proxy (kind of like connection pooling which is based on the connection string).
The article goes through a number of details on what's going on under the covers, but the main point is that you get a performance bump if you use ChannelFactory to create your proxy instead of instantiating it directly.
Hope this helps!!
This article explains that yes, there is TCP connection pooling for WCF. What it doesn't explain though is in which cases it will take effect. As far as I can tell, as long as you construct your proxy object by providing it a named endpoint (IE not using a custom Binding object), connection pooling will work. I tested this by throwing load at my web app and checking open TCP connections with netstat.
But the bottom line is you do not need to cache your proxy objects in order to re-use the TCP connections.