Background:
I've noticed that in my WCF services, when I throw an Exception (a plain old exception), the client channel enters the faulted state and has to be aborted and re-created before I can make another call on that channel. That's fine. That's how it's intended. I get it. So I just call abort() and re-create if I need to make another call.
However, faulting of the client channel only happens when I'm using a binding that has security enabled. When I use basicHttpBinding, I can get an exception on the client, and then keep using the ServiceClient object without it telling me it's in "the faulted state".
Also, when I turn off security on wsHttpBinding or netTcpBinding, I can re-use the channel after an Exception.
Question:
What is is about a binding's security that makes it fault the channel so it's unusable?
This is because with Security, you are setting up a secure session. When you throw out of that session, the channel enters the faulted state and you have to abort it and create a new one. With BasicHttpBinding, there's no session going on.
Related
I mean if a wcf client makes a call to wcf method, and then if wcf generates an exception which is uncaught at wcf side,
then it is my understanding that this error/exception at wcf side breaks the channel established between client/wcf by wcf proxy object(only if uncaught at wcf side)?
Is that true?
If true,then if i want to use same proxy object again (which was used to call wcf method when exception occurred) to make another call to wcf, may be in catch block at client end (may be for retrial of last call), then is there any way i can use that
or need to create/use new new proxy object?
I have created a wcf service with NetMsmq binding. And the operations are one way.
I wanted to handle the fault exception. However i found that the channel is not going to fault even after the exception is raised at the server side.
Can anybody tell me in what cases the wcf service will goes to fault state(provided while using NetMsmqBinding).
When throwing a FaultException from a WCF service, is there a way it can be thrown without faulting the actual connection? I'm looking to prevent an action for a particular method, but don't want to disrupt the client's connection (just return saying "you can't do this action right now, and here's why"). Or, is the required paradigm to recreate a new proxy in the .NET consuming app (in the case of .NET)
If you throw a FaultException then the client will get an exception but should be able to carry on using the same connection. If you let any other kind of exception out of the service (without having a Custom Error Handler in place) then it will fault the channel
Are you using .NET 4.0, can you use WebFaultException to return an HTTP status code with the appropriate error reason?
I have encountered a very interesting behavior of reliable session. I am using netTcp binding + duplex channel + reliable session.
When I am trying to listen on channel.faulted , if there is security mode is set to transport , faulted event would fire immediately when client disconnects.
However when I set binding's security mode to None or Message, faulted event no longer fires in the same situation. They will eventually get faulted half of ReciveTimeout on server side which I understands as reliable session would send a heart beat message at that time.
The question is: Why the wcf binding does not get faulted on time?
The workaround for this case is I can manually "ping" connections.
NetTcp binding by default uses Transport security with Windows credentials. All bindings except BasicHttp and WebHttp are secured by default.
Short Version:
When I've created a Channel using ChannelFactory on a client which uses duplex communication, do I need to keep the channel open in order to receive the callback or can I call ChannelFactory.Close()?
Long Version:
I'm developing my first WCF service and I've created my own ClientProxy Class, which implements and amalgamates a few different services into one. I use a ChannelFactory to create each channel, and my general reading on the net has indicated I should cache the ChannelFactory, but I should only open and close the actual channel when its needed.
So I call ChannelFactory.Open to open a channel and perform a duplex operation (a one-way operation which later calls a callback). Should I close this channel by calling ChannelFactory.Close after I've requested the operation, and if I do, will I still receive the callback?
Basic testing seems to indicate I will receive the callback if I close the connection however I just want to be sure. Also, is this method of caching the ChannelFactory correct?
Thanks
You should keep the client side proxy open while you wish to receive callbacks and when done you should close the channel.
Here's a quote from the great book Programming WCF Services by Juval Lowy (I suggest you to read the whole chapter about callbacks):
5.3.4. Callback Connection Management
The callback mechanism supplies nothing like a higher-level protocol for managing the connection between the service and the callback endpoint. It is up to the developer to come up with some application-level protocol or a consistent pattern for managing the life cycle of the connection. As mentioned previously, the service can only call back to the client if the client-side channel is still open, typically done by not closing the proxy. Keeping the proxy open will also prevent the callback object from being garbage-collected. If the service maintains a reference on a callback endpoint and the client-side proxy is closed or the client application itself is gone, when the service invokes the callback, it will get an ObjectDisposedException from the service channel. It is therefore preferable for the client to inform the service when it no longer wishes to receive callbacks or when the client application is shutting down. To that end, you can add an explicit Disconnect( ) method to the service contract. Since every method call carries with it the callback reference, in the Disconnect( ) method the service can remove the callback reference from its internal store.