So somebody (ok it was me) didn't realize you need to close WCF proxies after using them.
How bad is this? What kind of problems can it cause.
Is there just a delay in closing resources because of garbage collection - or should I really worry about things like premature app pool recycling?
I actually have far more ASMX than WCF proxies with this issue - so the same question goes for ASMX also.
Obviously now that I know this I'm going to gradually fix it, but would appreciate input on how bad this really is?
A WCF service has a default timeout. If you do not close it, the service will wait until there is a timeout.
WCF also has a max concurrent calls, that has a default of 10.
Therefore, if you do not close your connections you can only have 10 calls per min. (assuming default settings)
Here is someone with a similar problem:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/d58ee1c6-032b-40f3-b734-6628f3991bb2/
You can safely to reuse a WCF connection, just taking additional care to check if it's in a faulted state.
As a general guide when you are looking to gradually fix this, don't wrap your proxy's with a using statement, I've seen a lot of people do this, I was doing it until I read an article by IDesign that doing this might cause the Dispose to throw an exception and mask a real exception, explicitly close your proxy in try/catch, if close causes an exception, use Abort for resource clean up.
EDIT: As noted by the comment below this applies to WCF Proxies.
Related
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've got a WCF service that uses reliable sessions. In my tests, I tend to open a channel, call a method and then close the channel.
I often get a The session was closed before message transfer was complete. exception during Close().
Given that my method is synchronous, the message transfer should be complete. If it's reliable sessions causing this problem (because it's still doing something under the hood), surely it's responsible for either blocking my Close() call, or for giving up without throwing an exception?
How do I avoid this exception?
You should find what caused the connection close. Add diagnostics to you server and client config files by using the WCF Service Configuration Editor.
Repro the error and open your logs in the viewer. You will probably find that the message was to large at the serverside.
I had the same problem, the solution was to change operation contract in my interface definition by marking called method as IsOneWay=false which is default setting.
Make sure you haven't change your operation contract for your method to
[OperationContract(IsOneWay=true)]
What you may want to consider is specifying a timeout value in your call to Close() to allow more time for graceful closing. This can spare you many problems. (Although I agree that finding the cause and trying to prevent it is also important).
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'm currently playing around a little with WCF, during this I stepped on a question where I'm not sure if I'm on the right track.
Let's assume a simple setup that looks like this: client -> service1 -> service2.
The communication is tcp-based.
So where I'm not sure is, if it makes sense that the service1 caches the client proxy for service2. So I might get a multi-threaded access to that proxy, and I have to deal with it.
I'd like to take advantage of the tcp session to get better performance, but I'm not sure if this "architecture" is supported by WCF/network/whatever at all. The problem I see is that all the communication goes over the same channel, if I'm not using locks or another sync.
I guess the better idea is to cache the proxy in a threadstatic variable.
But before I do that, I wanted to confirm that it's really not a good idea to have only one proxy instance.
tia
Martin
If you don't know that you have a performance problem, then why worry about caching? You're opening yourself to the risk of improperly implementing multithreading code, and without any clear, measurable benefit.
Have you measured performance yet, or profiled the application to see where it's spending its time? If not, then when you do, you may well find that the overhead of multiple TCP sessions is not where your performance problems lie. You may wish you had the time to optimize some other part of your application, but you will have spent that time optimizing something that didn't need to be optimized.
I am already using such a structure. I have one service that collaborates with some other services and realise the implementation. Of course, in my case the client calls some one-way method of the first service. I am getting very good benifit. Of course, I also have configured it to limit the number of concurrent calls in some of the cases.
Yes, that architecture is supported by WCF. I deal with applications every day that use similar structures, using NetTCPBinding.
The biggest thing to worry about is the ConcurrencyMode of the various services involved, and making sure that they do not block unnecessarily. It is very easy to get into a scenario where you will be guaranteed timeouts, or at the least have poor performance due to multiple, synchronous calls across service boundaries. Even OneWay calls are not guaranteed to immediately return.
careful with threadstatic, .net changes the thread so the variable can get null.
For session...perhaps you could use session enabled calls:
http://msdn.microsoft.com/en-us/library/ms733040.aspx
But i would not recomend using if you do not have any performance issue. I would use the normal way, or if service 1 is just for forwarding you could use that functionality easily with 4.0:
http://www.sdn.nl/SDN/Artikelen/tabid/58/view/View/ArticleID/2979/Whats-New-in-WCF-40.aspx
Regards
Firstly, make sure you know about the behaviour of ThreadStatic in ASP.NET applications:
http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
The same thread that started your request may not be the same thread that finishes it. Basically the only safe way of storing Thread local storage in ASP.NET applications is inside HttpContext. The next obvious approach would be to creat a wrapper client to manage your WCF client proxy and ensure each IO request is thread safe using locks.
Although my personal preference would be to use a pool of proxy clients. Whenever you need one pop it off the pool queue and when you're finished with it put it back on.