Investigating memory leaks in remoting

There is a common misconception that using remoting leads to memory leaks. The fact is that the problems mostly lie in the server design more that in the use of remoting. There are two issues which often lead to server side leaks:

1. It could be related to [STAThread]. This attribute should never be used for a server side application. See my earlier post on why this could lead to leaks.

2. Issues related to lifetime management. If a server object has a infinite lifetime naturally these objects would never be collected and cause leaks. There are cases when infinite lease is necessary but in most cases these should be avoided. When an application profile shows only a few types of objects(inheriting from MarshalByRefObject) being leaked in a remoting scenario, first thing to look for is to see how the lease on these objects is being managed. Since there is no ref counting in remoting clients holding on to server resources is not an issue. All problems lie in how the server is managing its own lifetime. More about leases and lifetime can be found here.

If the app is running into a problem where the GC is not able to handle garbage at a decent pace it might be worthwhile to try if using the server gc helps its cause in any way. In general its probably anyway advisable to run the server process with server gc enabled anyway. An unmanaged host might be required to get this behaviour, but writing one should be trivial.