12.20
Usually in .NET, any object i instantiate i keep a reference to it until i don’t need it anymore, which is a common thing with any programming language. However, there are times when you don’t need a reference, you just want to call something and not care about the object. Which is what happened.
Basically the scenario is, i had a windows service that runs 24/7 which does data importing every x hours, with a number of data providers setup, all having their own times to import the data. And every 10 minutes, a thread is created to check to see if anything needs to be run, if it does, it runs it, if not then it just sleeps for 10 minutes again.
Now instead of actually calling a Thread.Sleep(10000), i figured it would make sense to use a Timer from the Diagnostics namespace, because i could say, in 10 minutes, call method X. Which was perfect! And it worked a treat. Sometimes.
All through development it was fine, through testing was fine (got very lucky, i guess) and then it went live, for the first few days it was fine (we were updating it quite alot so stopping-starting the serivce). Then it hit the weekend, come back monday morning, nothing. No imports since friday at 9pm. What the…?
Hunted through the code, nothing. It made NO sense that the data wasn’t importing, all the logic was there, i even called the other guys round for an idiot check. No-one could see the problem. So i thought, maybe an exception isn’t bubbling up correctly and we’re not getting it logged… Threw a whole host of extra debug logging in and re-deployed the service…sure enough, same thing happened again.
After about 30 minutes of reading up on the timer class, i realise 2 things.
1) It has a dispose method. Which means i should always have a reference to it, because when i’ve finished with it, i need to dispose of it.
2) MSDN is always the last place i look, but always has the answer. Why don’t i ever look there first?!
As it turns out, because the garbage collector in .NET (and rightly so) comes and clears memory when it wants to, any objects that don’t have a reference, will get nuked. Which is exactly what was happening. We were setting the timer, then sometimes, .NET was coming along and clearing it because we had no reference to it. Therefore preventing the importers from running, and the service of course was still running…but not actually doing anything as the main timer’d thread was killed off.
Now i have a member of the class which has a reference, and i dispose of it when the service stops/restarts.
It’s really weird, i knew .NET did that, but it didn’t even occur thats what could be happening. But, we all learn from our mistakes!
So, Keep a reference to your objects and make sure you dispose of them when your done! Don’t make the mistake i did…
Hehe, the garbage collector is great when it’s on your side but a real pain when you get in it’s way (or it in yours). I have a generic system similar to the one you described deployed at several clients and know the perils of IDisposable all too well.
I’m facing a slightly different problem at the moment: my service runs for months without a problem, but then will suddenly stop importing files when nobody is looking. I am holding a reference to the timer, so it can’t be the gc. I’ve seen it happen in at least two completely unrelated systems (one of which is no longer in use). I’m beginning to suspect theres a bug in long running timers that causes them to stop after a certain number of ticks or days or something (but with such a long period of time between occurrences it’s a nightmare to test).
Anyway, it’s just something I thought you might want to be aware of in case it crops up in your project. I’ll be sure to come back and let you know if I find a cause and/or solution. As for MSDN, it’s permanently open and bolted to my secondary monitor ^_^