Last post Jul 22, 2009 04:21 PM by mike426
Jul 20, 2009 09:20 AM|beginner_|LINK
I need to use a com object for a certain task and this task is pretty memory-heavy. Now the problem is that the com object is somehow not released correctly since the emmory consumed by the worker progress increases linearly with how often I ran this task.
Note that this is an objectdatasource select method:
GetCodeCOMType = Type.GetTypeFromProgID("MyProgID")
MyCOMObject = Activator.CreateInstance(GetCodeCOMType)
If Not IsNothing(MyCOMObject) Then
MyCOMObject = Nothing
So I'm a little lost on how to remove this object from memory.
Jul 20, 2009 04:22 PM|mike426|LINK
You're using different syntax than I usually use to get an instance of the COM object, but I don't think that's a problem. To release the COM object, I usually do it in a loop:
While System.Runtime.InteropServices.Marshal.ReleaseComObject(MyCOMObject) > 0
I don't think you need to set the variable to "Nothing", but your code will be doing everything it needs to if there's just one reference to the COM object (which there probably is). If you somehow have two references to your COM object, then you would
be leaving one reference out there and the object wouldn't be released - however, that's probably not what's going on.
If you're dealing with a COM component written in unmanaged code, then there could be a problem within the COM component which isn't allowing the memory to be released. If you're calling methods on the COM component which return complex types, make sure
you release these variables when you're done with them.
I'm assuming this is an in-prcess COM component (in a .dll). If there's an out-of-process version of the component (in an .exe), then you might try using this since memory consumed by the component would be released when your code releases the COM component
and the component exe process exits.
Our company's approach is to put problem code like this (i.e. code where exceptions are being thrown or memory doesn't seem to be released) in an expendable worker process (separate from w3wp.exe) which is recycled frequently. You're not stopping the memory
leak, but you're getting around the issue by recycling the processes.
Jul 21, 2009 01:25 AM|beginner_|LINK
I will have to check the Com object. You are right, that the problem probably occurs there.
Jul 21, 2009 08:06 AM|beginner_|LINK
I found the issue but no solution, cause none really available. The com object is actually a very simple Python Com-server (around 20 lines of code for the method). I wanted to use it for a certain feature to be easly available. This feature is available
through a commercial Python extension and the leak actually happens in this extension in the one specific method I would like to use.
Jul 21, 2009 10:21 AM|mike426|LINK
OK - I think you either need to recycle the worker processes in your application pool frequently, or isolate the COM component in another process and recycle that external process frequently. You could put the code that calls into the COM object into a
web service, and host that web service in it's own application pool and recycle the worker processes in that application pool frequently. Our company's product uses .NET remoting to host the problem code in external processes on the same machine with which
we communicate over the IPC channel. The external processes can likewise be recycled based on criteria like the number of calls serviced, etc. I'm sure you can accommodate the leak - you just need to implement this recycling by one means or another.
Jul 22, 2009 02:36 AM|beginner_|LINK
Well you got me there. I'm not like an expert and this app is nothing very big or crucial and it would work flawlessly without this additional feature. Anyway what I mean is that I have no idead how I would implement your ideas (expect maybe the webservice).
I put the app in a separate Application Pool and used a time and memory limit when to refresh. At least the memory limit seems to work.
For now this is good enough though I'm not quite sure what it means to refresh the worker process quite often.
Jul 22, 2009 04:21 PM|mike426|LINK
Theoretically, the worker process being recycled should finish what it's doing prior to being terminated, and new requests should automatically be handled by a new worker process - so the recycling should be transparent to the end users. I've seen an issue
where we were recycling worker processes frequently and new requests weren't being handled by the new worker processes, but that was probably something specific to our environment. If the application isn't critical, then you can afford to just monitor it
for a couple of weeks with the new recycle frequency setting. If users are complaining about losing their sessions then post to the thread again and I'm sure we'll get some input on new approaches.