Handling OOMs in new AppDomain

[ttrudeau]

Currently, I'm playing with some ideas on recycling application components
for a service application when the individual parts die, because of an OOM.
As a start to this I created a secondary AppDomain and created an instance of
a class in that application domain that throws an OutOfMemoryException on an
interval.

I hooked up the AppDomain.UnhandledException event, but it isn't getting
called. I can watch the output that says, "A first chance exception of type
'System.OutOfMemoryException' occurred in ..." But, nothing happens and the
class seems to continue on its merry way. The error is thrown by an event
handler (handling the Timer.Elapsed event).

What is the proper way to handle exceptions in this context?

 

[Brian Gideon]

Currently, I'm playing with some ideas on recycling application components
for a service application when the individual parts die, because of an OOM.
As a start to this I created a secondary AppDomain and created an instance of
a class in that application domain that throws an OutOfMemoryException on an
interval.

I hooked up the AppDomain.UnhandledException event, but it isn't getting
called. I can watch the output that says, "A first chance exception of type
'System.OutOfMemoryException' occurred in ..." But, nothing happens and the
class seems to continue on its merry way. The error is thrown by an event
handler (handling the Timer.Elapsed event).

What is the proper way to handle exceptions in this context?

Are you trying to isolate memory leaks? Recycling application domains
may not fix the problem especially if the leak is occurring in
unmanaged code.

 

[ttrudeau]

Initially I'm focusing on OOM issues, but really any unhandled exception.
After that I'll move into some health monitoring to ensure there are no
endless loops, etc. The different objects will be running user developed
code and workflows, so I cannot guarantee the reliability of those parts, but
I do want to be able to guarantee the reliability of the service as a whole.

Do you have any other suggestions if loading and unloading an application
domain will not provide that reliability?

 

[Brian Gideon]

Initially I'm focusing on OOM issues, but really any unhandled exception.
After that I'll move into some health monitoring to ensure there are no
endless loops, etc. The different objects will be running user developed
code and workflows, so I cannot guarantee the reliability of those parts, but
I do want to be able to guarantee the reliability of the service as a whole.

Do you have any other suggestions if loading and unloading an application
domain will not provide that reliability?

Well, recycling application domains is definitely a good start at
increasing the reliability of the service especially since it sounds
like you'll have some sort of plugin architecture where you don't have
a lot of control over the plugin code. It should solve some OOM
exceptions.

As for the exception handling...I don't have lot of experience using
AppDomain.UnhandledException, but it sounds like the debugger may be
intercepting the exception before it is propagated to that event
handler. Have you tried testing the code outside of the debugger?

 

[ttrudeau]

That's an interesting idea. I just tried running it without the /DEBUG
switch to see what happens and the exceptions are still swallowed.