Over the last week at work, we have been doing some testing of our [WCF] services that call into a business layer that uses [WF]. We have the services set as single instance, and we are using a new instance of the WorkflowRuntime for each service call. There are obvious inefficiencies of creating the runtime for each call, but that isn't the issue. The problem is that we noticed that the memory went up and didn't get released (until the AppDomain was unloaded).
After a lot of testing, it came down to the WorkflowRuntime instances that were remaining in memory, even through all of our other objects were cleaned up and disposed. We did everything we could to release the runtime from our code but the memory issues remained. So, is there are memory leak in the runtime?
The solution seems to be to wrap the runtime as a singleton. Singletons have been bashed a lot over recent months and while I agree with the criticism over the misuse/overuse of singletons, I think this is an appropriate case for one. Initial testing has shown that there is no memory problems once only a single WorkflowRuntime was used. This also comes with the performance benefit of not having to create and destroy the runtimes for each call.
Scott Allen has some more pitfalls to watch out for with the runtimes.
I am a little curious about how the garbage collector cleans up CLR objects. From what I understand, it will wait until objects are de-referenced and then will go through a couple of generations (as required) to release objects from memory.
The following is a simple scenario of GC:
Object A that has a reference to B that has a reference to C. When A goes out of scope, the GC can collect it. When it removes A, B is has a reference count of 0 and can also be removed and then likewise for C as B is removed.
Side question: does this happen in the same GC cycle or is this over three GC cycles?
Ok, simple enough. But how does the GC handle the following scenario:
Object A has a reference to B which has a reference to C. C has a reference back to B.
When A goes out of scope, is B available for the GC as it is still referenced by C? How does the GC handle these circular references?
10. April 2007
Using MCE has been quite a good experience for me. The exception to this is PRIME which for me is notoriously jittery. One thing I did notice recently is that when the daylight saving change happened recently, my recording times got thrown out by an hour.
I find it strange that if I want to record from 8:30pm-9:30pm that this is stored against (presumably) a UTC value. Surely it would be better if MCE just stored the local time. It's not like I'm going to take my box to another time-zone and still have relevant scheduled recordings.
What is this? Well, that would be Mt Rogers. You will have to trust me on that score.
Looks like this is the first decent fog of the season. Now if we can just get some of this stuff, everything will be shiny!