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
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
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
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.
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.