Musings from the basement of a very tall building
Posted By Robin Freeman | last update 15-Aug 2010
In the early naughties a terrible pestilence stalked microsoft application server land. It wasn't if, but when, a memory leak would take your server down. Lets be clear; a client or workstation machine sits on its hands most of the time and waits for its user to peck at its keyboard or move its mouse. A server shouldn't have a user, it sits on its hands waiting for a request for information (from a workstation) via its network. It will then start up some application that ends up sending that information.
A server might have a hundred applications that each get used a hundred times a day. This sounds like a lot of work, but the applications may need to run for microseconds only. The important point is that when they finish they return any memory (and other resources) they use back to the operating system. If they do not, and at the time we are considering, each application instance kept 20-40kB of memory for a variety of reasons; the server runs out of memory and crashes. No I never did find the memory leak in my web applications, and yes I did just routinely restart the server every 4 weeks to overcome this problem.
Aware of this, microsoft revised its application development tools for the Visual Studio 2003 release. Working in a fundamentally different ways to anything that had preceeded, the most important point was that the code produced was managed as it ran. Only those parts required were run and they were destroyed after completion. The memory leak was gone, all hail the .net framework upon which this rests.