Be aware that this is not always true. The GC knows nothing about handles, only memory. Given a machine with enough memory, not a lot of GC pressure and long lived, you can run out of handles. This is why we have “hacks” like the HandleCollector class: http://referencesource.microsoft.com/#System/sys/system/runtime/interopservices/handlecollector.cs, which forces a collection after a certain threshold of handles. But we don’t use this to track this automatically for you.
From: [email protected] [mailto:[email protected]] On Behalf Of Greg Keogh Sent: Thursday, August 21, 2014 12:40 AM To: ozDotNet Subject: A Disposable warning Folks, lots of things in the FCL implement IDisposable and forgetting to dispose of most them won't normally cause any damage. The garbage collector runs at unpredictable intervals and finds things like forgotten streams and DB connections and cleans things up long before you'd hit things like handle limits. However, I had a svcutil generated proxy class with two Dispose methods and I had the cleanup code in the wrong one. This went unnoticed for months until I looked into why we would get occasional random pauses or hang-ups in the service during heavy bursts of use. Stepping way down into the code I found the wrong Dispose, and fixing this cured the problem. It turns out that WCF services have a default limit of 10 (or 16?) connections after which new ones block. Because the clients weren't being disposed, they would hang around for a random interval until the GC took them. If their instance count randomly reached the WCF limit then the service would pause or stall. So the problem was caused by an unfortunate combination of the coding error and the environment. Beware ... Dispose carefully and often! Greg K
