I'm having a problem where the WCF service hangs after 13-14 asynchronous process calls from the client. This occurs all the time. The client is a mobile JavaFX app. There is no specific error outputted in the server as well as in client. Someone suggested that it might be a throttling issue.
I've set the service side .config parameters maxConcurrent calls from 10 to 500
<serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500” />
So this means, it should be able to accept more than 10 calls, right? However, it didn't resolve this issue. Still hangs on the 13-14th process call.
Only one client is connecting to this web service.
What do you think is wrong?
Do you close the client after doing your call?
When I encountered this problem, I did not close it, and the open requests blocked the service after a short time.
Edit: Ok, I know nothing about JavaFX =) The code below is C#, sorry. But you can surely do something similar.
Use either
WcfClient client = new WcfClient()
// ...
client.Close()
or
using(WcfClient client = new WcfClient()){
// ...
}
Similar problem here - I have an app calling from one process to another, locally, named pipes.
Calls are really light in code- basically takex an array of serializable objects, queues them on other side. Occasionally it hangs. Restarts afte rtimeout. no data lost, but... as the data is financial data, and the receiving app an autoamted trading system, that may result in very bad financial issues. Not been able to reproduce it yet.
This could very easily be caused by any deadlock condition in your code. If your service locks up and starts eating up 100% or CPU you have a dead lock. Create a dump file and see where your code was at.
I ran into the same issue my first WCF app it was a dictionary that i wasn't making sure was synchronized in logging code.
The SvcTraceViewer is super helpful in figuring out tough wcf
Related
I have a situation where I have two programs (one exe and one dll loaded into the process space of another third-party exe) communicating requests with each other using a local machine wcf service (using net named pipe binding). There's a third host exe that starts hosting the service. It all works great (so far anyways... I'm still learning), but I got to thinking about what would happen if the channel faults or the service times out. What would be the best practice for checking and handling faults as well as keep the channel alive?
In my case it will be up to the user to keep the applications open or close them and we do have those users who tend to keep them open overnight, over the weekend, etc... It seems to me this could open the possibility of a fault or loss of service and I don't have a clue how to recover. Any help would be greatly appreciated.
Firstly, why would you keep the channel alive indefinitely?
Imagine you are connecting to a database from which you want to read over the course of one day. Would you create the database connection in the morning and then close it in the evening?
It is relatively cheap to construct a channel in WCF for each call, unless you know you are going to be making multiple calls within a few seconds of each other, in which case you should reuse the channel.
EDIT
This post explains how to do it. It's pretty complicated and it may be easier to just set a huge timeout value for the binding in code (as suggested at the end of the post):
Do WCF Callbacks TimeOut
EDIT
There's tons of stuff on google about this: http://bit.ly/10ZPWE2
Error code:"
The request channel timed out while waiting for a reply after 00:09:59.6320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding."
This error occurs infrequently when calling a Wcf service methods. It doesn't matter what method is. I have created test methods that returns simple strings. Sometimes it times out, sometimes it works perfectly. The strange thing is that when the WCF service is published on one server(for testing purposes)- there is no timeout. When I publish it on another server(live/public) there occurs these timeouts infrequently. I have set the timeout to 10 min as you could see above.
The webconfig setting should be correct, because it works for the one server. The only change made is the ip address. I know this is very difficult to answer and a bit ambiguous.
I'm sure this problem is too high level for me to solve, or maybe I'm making a simple mistake and it is too obvious for me to notice. If you could give me a pointer or just friendly advice on this problem I would really really appreciate it. I am shooting in the dark here. I thank you for your interest, proved by you reading up to here.
does it happen first time you call the service? if not, but does subsequently, it could be that the service instance has been locked by the calling thread - look into multiple instances or allowing concurrent use, obviously taking into account the thread safety requirements of your code
Hi have quite a problem with an Service running WCF in duplex-mode.
It leaks memory (not much but it's about 80MB a day) and after having a memory-profiler running alongside the service for 24 hours I found most of the memory sitting in byte[] referenced by quite a mess but I most references end in something like this:
and the "root" looks like this:
I too see lots of ServiceChannel (around 200) comming (I think) from the callback-channels.
I'm rather sure that I only hold 1 of those for each of the connected clients.
Overall my problem seems to be almost the same as this: memory leak in silverlight Wcf implementation but on the server-side.
I even tried the [MTAThread] thing mentioned here: WCF service leaks handles and memory when a client times out but it just don't solve the problem.
I just don't think that the problem is with my code as I wrap the callback-channels after getting it with OperationContext.Current.GetCallbackChannel<IServiceConnectorCallback>() in one of my own objects and those don't leak (there is only one of those for each clients in memory at any given snapshot) - sure I reset those callbacks on several occasions as the channel might change (clients losing the connection or reconnecting) but I don't have a way of disposing the old references so I only drop them and the GC should do it's job on them.
I do use PerCall on my service so I don't have any handle to those objects in my code at all.
I really have no clue at how I can handle this aside from restarting the service every few days - a solution I don't want to probose right now :(
So please give me some help/hints on this - thank you very much!
When a session based channel faults a call to Close will throw an exception. However, there are proxy side resources that are not cleaned up in this case and these are only cleaned up when you Abort the faulted channel
Make sure that when you replace a faulted channel that you Abort the old one first
I'm working on shipping in a change for my lab that will hopefully help diagnose some weird channel-faulting weirdness we're seeing. There's a test application that uses DuplexChannelFactory to connect to a couple windows services, and for some reason the channels on this test application seem to be faulting quite a bit. I have plans to implement some retry logic in there, but it would be great to figure out why exactly they're faulting.
I know that channel factories and proxy objects all implement a lot of interfaces, and I've used reflector to crawl through some of them, but I haven't found anything like what I'm looking for. Is there a way to query these objects after they've faulted in order to get some information about what caused the fault?
Edit: The configuration is very basic--the binding is just the default-constructed NetTcpBinding, the service implementation has [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)], and no special attributes are on any of the operations in the service contract. However, I'm asking more about general techniques in diagnosing channel faults, not diagnosing this specific case. I wouldn't expect configuration specifics to have too much impact on that; if anything, the configuration details would be something returned by said diagnostics, right?
Ladislav and Shiraz answers are all good and I have gave them +1.
All I can add to them is that normally a faulted channel is the result of unhandled exception on the server. When that happens, WCF thinks that there is somethig fundamentally wrong with the server and faults the channel so that it cannot be used.
The correct approach - which I believe should have been default and come for free - is for the service to catch the exception and create a FaultException and return it (look at this form example http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)
The reason WCF does not make as default is that it changes the contract and the WSDL so the client has to get the updated WSDL.
So if I were you, I would catch the exceptions, log them and then return a fault exception and this way I would know what the problem is and channels are not faulted.
First thing is it this test application, or are the specific services used by other clients.
Assuming that it is the test client that is causing the problem. There could be 2 problems:
Not closing proxies, therefore hitting max connections to the server.
Not aborting proxies when they are in a failed state.
Diagnostic tool you are looking for is called WCF Tracing. It usually shows why the channel has faulted. You can configure it on both client and server and use SvcTraceViewer.exe to browse collected traces.
Have you hooked on to the ICommunicationObject.OnFauled
I have the standard error handing in place in my service:
I have an IErrorHandler hooked to the service to handle unexpected errors during service execution.
I have try/catch blocks in all my service methods to handle expected cases.
However, there are cases where exceptions are thrown on the server and neither is called.
Here is a case where the server exception is not sent to the IErrorHandler:
Set the receiveTimout on the server binding to 5 seconds.
On the client do this:
.
Service1Client sc = new Service1Client();
ICommunicationObject o = sc as ICommunicationObject;
o.Open(); // open channel
sc.GetData(10); // do a first call
Thread.Sleep(10000); // wait longer than the server receiveTimeout
sc.GetData(10); // Attempt another call: server throws a FaulException
In that case, the error is thrown on the server but I cannot find a way to handle it (and log it). I know an error is raised because if I attach a debugger on the server process and break on all exceptions, the debugger breaks.
I have found other similar cases where low level errors are not passed to my program.
Where can I hook my code to ensure that I can handle ALL exceptions that occur on the server before they are returned to the client app? Should I implement my own IChannel or some other low level interface?
Thanks
UPDATE Sep 21 2009: See this thread on the Microsoft WCF Forum. I'll probably have to implement my own Channel if I want to handle this type of exception. I'll update this post again when I have more info.
After much research and experimentation, the answer is:
At this time (.Net 3.5) there is no mechanism that allows one to handle all possible exceptions that may occur in the context of a WCF call.
Exceptions that happen during the service method execution can easily be handled with:
Try/catch blocks in all service methods to handle expected cases.
IErrorHandler hooked to the services to handle unexpected errors during service execution.
However, for low level WCF infrastructure errors, there is no perfect solution. The best solution that exists seems to be to implement a custom channel to catch more exceptions.
In this Microsoft Connect Bug Report, Microsoft confirms that there is no way to handle all types WCF infrastructure errors.
In this thread on the Microsoft WCF forums, there is a sample on how to implement a custom channel. That solution only works for HTTP, not for HTTPS. Also some WCF infrastructure errors are not caught by the custom channel either (see more details in that specific thread).
Use FaultContracts. Then the fault can be handled at the client end.
http://msdn.microsoft.com/en-us/library/ms732013.aspx
http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx
This is also much better for debugging, since often you will be developing a client and don't want to bring down the server for debugging purposes.
On the client end, use try/catch blocks to catch all exceptions/faults. There are definitely errors that can't be detected on the server end, such as a communication problem, so you need to handle errors on the client end anyways.
If you want centralized error handling, you can create a service that takes messages about all errors, send the error to that server, and have it log that. This can be useful if you want to create a centralized message tracing/performance analysis/logging tool and have a large number of application processors, servers, clients etc.
The point is - if the server is not reachable or can't handle the message, there won't be an error on the server - the error will pop up on the client ("TimeoutException" or others).
So in those cases, having the IErrorHandler on the server really isn't gonna help - since the error really happens on the client (no connection can be made, due to network down, or typo in server's address or sstuff like that).
So on the client side, you definitely also have to use try....catch around all your server calls.
Marc
Set up diagnostic tracing and check the logs with Service Trace Viewer Tool. Link contains information about configuring tracing as well.