Is there a way in a WCF service to catch a client timeout I need to run some special logic on a client timeout.
I have not found any sources indicating a WCF service can check if a client timeout through service side Error Handling, Etc... if you require more information let me know.
Anything that needs to be cleaned up in your service, should be cleaned up regardless of whether there was a client timeout, a client disconnection, or an exception in the service.
Do your cleanup in the finally block of a try/finally, or, if you clean up by calling the Dispose method of an IDisposable object, then use using blocks.
Related
I have implemented message layer security using message inspector mechanism in a wcf service.
On the client side, in IClientMessageInspector.BeforeSendRequest I add an authentication header.
On the service side, in IDispatchMessageInspector.AfterReceiveRequest I inspect the authentication header in the message. If it is not found or as expected, I throw a SecurityException and try to log it to a database.
Here comes the interesting part. When logging to database, I try to read from this webservice again (this is web service which provides configuration info).
This is where the service stalls/deadlocks. I can see that the call to read configuration (when logging to db) is made, but I don't receive the call on the service. I keep getting a timedout exception every time.
After a little googling, I came across this post, which mentions that message inspectors are synchronous in nature. If that is so, how can I achieve what I am after?
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 a WCF service hosted as Windows Service with most of its methods currently defined as:
[OperationContract(IsOneWay = true)]
But, now I need to send response back to the calling Web application for these service methods.
Now, because service methods are bit heavy (FYI, they are reporting methods that needs to do mail merge for a no. of records), I am thinking to either queue them or to process asynchronously, so essentially when the request is sent to the service it should save the request to database/queue, returning Request-Id to calling Web application.
In the mean-time, WCF service can just process incompleted requests from the queue or database.
Then either calling Web application can ping WCF service for status of request because it has Request-Id or
WCF service can ping back to calling app when the process corresponding to a Request-Id is completed.
To achieve above, can anyone please guide what changes I need to make to my WCF service (which currently has all one way operation)?
Also, please guide me whether I need to go for Asynch operation or message queuing?
Thank you!
Of course, going Async is simple:
remove the OneWay on the OperationContract in question and regenerate your Service WITH Async methods. There's a reason why Silverlight forces you to use Async operations. They do force you to rethink your UI.
I've setup an example in which a client calls a WCF service that has a Callback registered. It all works perfectly, but I want to test the scenario in which the client is closed, but the Service is still doing it's thing. Then when it comes time for the Service to call back to the client, I get an error because the client ain't there anymore. Is there a recommended way for me to validate in the Service that that the client is still there before trying to call back to it via the CallBack channel? I've tried accessing OperationConext.Current(), but this is null in the context of the callback method.
--Shawn.
You have already found one recommended method - call the client and see if it works.
TCP/IP can't always detect client shutdown. In particular, it's often necessary to send a packet to the other side to see if it is still there.
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.