VoIP Mailing List Archives

[mgg at giagnocavo.net]

The ILoadNotifcationPlugin is run in the appdomain created for the plugin, so it should only get unloaded when the plugin gets reloaded. Spawning threads here should work, it's definitely the intention that if you need a long-running process, you can fire it up on load and have it work.

As to the race condition on reload, mod_managed should do this:

- Load the new plugin into a new appdomain
- Remove the entry points to the old appdomain, add entries to the new one
- Old appdomain now stays alive until foreground API and APP calls finish

So, you can have many versions of the same plugin active in memory.

I probably need to go break compatibility and make ILoadWhateverPlugin be something like IPluginController and allow it to return loading options to control the mod_managed behavior, as well as allow it to delay shutdown of the appdomain. Part of the question is: how many people out there need compatibility, or can we go breaking all of you and make you recompile?

Although, IIRC, if you handle AppDomain.Unload (or whatever it is), it will stay alive until your event handler completes.

Hope that helps a bit.

-Michael


-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jeff Lenk
Sent: Wednesday, September 09, 2009 1:57 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


I think the problem here is that the loader only keeps this method in scope
until completion then it drops the remoted connection. Therefore you should
not use threads in this method. Michael please correct me if I am wrong
here.

As an example of the failure simply just put a Sleep(10000) call in the
thread and you will see the failure.

As Michael said this method was only designed to allow the option to opt out
of being loaded.

In order to support this perhaps a configuration flag simular to the lua
"startup-script" should be added.



Here is the error I get with the loop I mentioned. -Josh
[image: Capture.PNG]

On Tue, Sep 8, 2009 at 5:05 AM, Michael Giagnocavo
<mgg@giagnocavo.net>wrote:

[mgg at giagnocavo.net]

[josh at radianttiger.com]

I have a new thought on the crashes...I'm able to crash FreeSWITCH any time I like, just by having an exception in a thread.
    public class CrashFreeSWITCH : ILoadNotificationPlugin
    {
        public bool Load()
        {
            ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });
            return true;
        }
    }


Perhaps Application.ThreadException or AppDomain.UnhandledException need to be trapped?


On Wed, Sep 9, 2009 at 4:51 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[mgg at giagnocavo.net]

That’s by design. If a thread fails, and there’s no handler, then the application could be in a corrupted state, so the CLR takes down the process.

I think there is a .NET 1.0 compat switch you can enable in the config if you like exceptions to be silently ignored J.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 6:39 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


I have a new thought on the crashes...I'm able to crash FreeSWITCH any time I like, just by having an exception in a thread.

public class CrashFreeSWITCH : ILoadNotificationPlugin

{

public bool Load()

{

ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });

return true;

}

}



Perhaps Application.ThreadException or AppDomain.UnhandledException need to be trapped?



On Wed, Sep 9, 2009 at 4:51 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[josh at radianttiger.com]

The question is whether the CLR should take down the whole phone server due to an unhandled exception...definitely the CLR should terminate...but shouldn't it just log the exception to the console, not crash the core?

On Wed, Sep 9, 2009 at 6:30 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[mgg at giagnocavo.net]

Well, a segfault in voicemail would do the same thing.

Suppose your plugin runs a thread that does something important, like billing or so on. That thread fails – do you really want it to go on?

Anyways, the solution is simple enough, handle your exceptions J. Every plugin can decide what it wants to do here.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 10:41 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


The question is whether the CLR should take down the whole phone server due to an unhandled exception...definitely the CLR should terminate...but shouldn't it just log the exception to the console, not crash the core?
On Wed, Sep 9, 2009 at 6:30 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
That’s by design. If a thread fails, and there’s no handler, then the application could be in a corrupted state, so the CLR takes down the process.

I think there is a .NET 1.0 compat switch you can enable in the config if you like exceptions to be silently ignored J.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 6:39 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




I have a new thought on the crashes...I'm able to crash FreeSWITCH any time I like, just by having an exception in a thread.

public class CrashFreeSWITCH : ILoadNotificationPlugin

{

public bool Load()

{

ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });

return true;

}

}



Perhaps Application.ThreadException or AppDomain.UnhandledException need to be trapped?



On Wed, Sep 9, 2009 at 4:51 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[jlenk at frontiernet.net]

Thanks Michael,

I was seeing some strange behavior in a static compiled dll versus
dynamically loaded and compiled scripts.

This code when used in a dll was blowing up when a thread was spawned in the
ILoadNotificationPlugin.Load but is not when used in a dynamically loaded
script(csx).

Code:

ThreadPool.QueueUserWorkItem((o) =>
{
Log.WriteLine(LogLevel.Notice, "Thread Starting. ");
while (true)
{
Thread.Sleep(10000);
Log.WriteLine(LogLevel.Notice, "Thread Running.
");
}
});

I will look into this more later.

Jeff



Michael Giagnocavo wrote:

[mgg at giagnocavo.net]

Were both of them actually loading completely? As in, they had an app or api plugin?

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jeff Lenk
Sent: Thursday, September 10, 2009 8:34 AM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


Thanks Michael,

I was seeing some strange behavior in a static compiled dll versus
dynamically loaded and compiled scripts.

This code when used in a dll was blowing up when a thread was spawned in the
ILoadNotificationPlugin.Load but is not when used in a dynamically loaded
script(csx).

Code:

ThreadPool.QueueUserWorkItem((o) =>
{
Log.WriteLine(LogLevel.Notice, "Thread Starting. ");
while (true)
{
Thread.Sleep(10000);
Log.WriteLine(LogLevel.Notice, "Thread Running.
");
}
});

I will look into this more later.

Jeff



Michael Giagnocavo wrote:

[pjintheusa at gmail.com]

Surely this is because you are calling ev.serialized_string and ev is null if there is not event waiting?

i.e.  con.pop(0); returns null if no event is waiting.


Therefore


if(ev != null)
      Log.WriteLine(LogLevel.Notice, "Event: " + ev.serialized_string);


would work, alternatively calling 


                    Event ev = con.pop(1);


would block until an event is available - and therefore ev cannot be null....







On Wed, Sep 9, 2009 at 2:01 PM, Josh Rivers <josh@radianttiger.com (josh@radianttiger.com)> wrote:

[josh at radianttiger.com]

I'm only concerned with the difference in treatment.

public class CrashFreeSWITCH : ILoadNotificationPlugin
    {
        public bool Load()
        {
            ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });
            return true;
        }
    }
Crashes the entire switch, terminating all calls and disconnecting from the PSTN.
public class CrashFreeSWITCH : ILoadNotificationPlugin
    {
        public bool Load()
        {
            throw new NotImplementedException();
            return true;
        }
    }
Logs a message to the console and doesn't load the module, while leaving the switch operating.


In my experience, exceptions in multi-threaded code: a) happen, b) are hard to diagnose. Is the best behavior for the environment to crash, providing no diagnostic information? That's hard in development, and even harder in production. I suppose 'terminate switch on fault' should be an option, to allow the operating system to restart the whole process on fault conditions, but if that is the intended result, shouldn't any fault do the same thing? What if the billing was happening in my second code block?


Normally, I'd trap the ThreadException and UnhandledExceptions in my application, so that my code could choose the correct actions to perform should the application get into an unknown state. This can include terminating the whole application, but also logging diagnostic information, trying to save uncommitted data, and sending notifications of the failure.


Is 'crash if it's a thread, but not if it's not' good because it's the way the module works now, or is it a better design for a reason I'm not understanding?
 
On Wed, Sep 9, 2009 at 11:09 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[mgg at giagnocavo.net]

Well, we have absolutely no idea what the background thread is doing. It might be critical, and the fix is trivial: put a try/catch on it. This is the model all .NET applications have. Background threads doing bad things should always take down the process.

However, that’s a good point about Load() failing. The approach taken is more or less how FreeSWITCH handles things in general now. If a module has an error, the switch just logs and goes on. I’m not really in favour of this, and suggested at least a “required” attribute in the modules.conf that would prevent the switch from loading if the module fails.

The fix is probably to create an attribute you can apply to the plugin classes that indicate what kind of failure handling you want. For the assembly, we’d add an attribute with an enumeration like:
<![if !supportLists]>- <![endif]>Default (scan, call ILoadNotificationPlugin, log errors if they occur)
<![if !supportLists]>- <![endif]>NoLoad (don’t load the assembly)
<![if !supportLists]>- <![endif]>Critical (stop the switch if there’s an exception during loading)

That’d provide the control you want for loading. We could do something similar for App/Api plugins.

I want to move ILoadNotificationPlugin from being this “catch all” thing that controls the entire assembly to something that can be used to fire up code; effectively “OnLoad” and “OnUnload”. To dynamically control loading, we’ll probably reflect on the individual plugins looking for attributes or perhaps some sort of static load function.

How’s that sound?


From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Josh Rivers
Sent: Thursday, September 10, 2009 12:48 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


I'm only concerned with the difference in treatment.

public class CrashFreeSWITCH : ILoadNotificationPlugin
{
public bool Load()
{
ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });
return true;
}
}
Crashes the entire switch, terminating all calls and disconnecting from the PSTN.
public class CrashFreeSWITCH : ILoadNotificationPlugin
{
public bool Load()
{
throw new NotImplementedException();
return true;
}
}

Logs a message to the console and doesn't load the module, while leaving the switch operating.



In my experience, exceptions in multi-threaded code: a) happen, b) are hard to diagnose. Is the best behavior for the environment to crash, providing no diagnostic information? That's hard in development, and even harder in production. I suppose 'terminate switch on fault' should be an option, to allow the operating system to restart the whole process on fault conditions, but if that is the intended result, shouldn't any fault do the same thing? What if the billing was happening in my second code block?



Normally, I'd trap the ThreadException and UnhandledExceptions in my application, so that my code could choose the correct actions to perform should the application get into an unknown state. This can include terminating the whole application, but also logging diagnostic information, trying to save uncommitted data, and sending notifications of the failure.



Is 'crash if it's a thread, but not if it's not' good because it's the way the module works now, or is it a better design for a reason I'm not understanding?



On Wed, Sep 9, 2009 at 11:09 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
Well, a segfault in voicemail would do the same thing.

Suppose your plugin runs a thread that does something important, like billing or so on. That thread fails – do you really want it to go on?

Anyways, the solution is simple enough, handle your exceptions J. Every plugin can decide what it wants to do here.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 10:41 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




The question is whether the CLR should take down the whole phone server due to an unhandled exception...definitely the CLR should terminate...but shouldn't it just log the exception to the console, not crash the core?
On Wed, Sep 9, 2009 at 6:30 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
That’s by design. If a thread fails, and there’s no handler, then the application could be in a corrupted state, so the CLR takes down the process.

I think there is a .NET 1.0 compat switch you can enable in the config if you like exceptions to be silently ignored J.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 6:39 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




I have a new thought on the crashes...I'm able to crash FreeSWITCH any time I like, just by having an exception in a thread.

public class CrashFreeSWITCH : ILoadNotificationPlugin

{

public bool Load()

{

ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });

return true;

}

}



Perhaps Application.ThreadException or AppDomain.UnhandledException need to be trapped?



On Wed, Sep 9, 2009 at 4:51 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[raffaele.p.guidi at gm...]

I want to move ILoadNotificationPlugin from being this “catch all” thing that controls the entire assembly to something that can be used to fire up code; effectively “OnLoad” and “OnUnload”. To dynamically control loading, we’ll probably reflect on the individual plugins looking for attributes or perhaps some sort of static load function.

I meant to do something like that probably using spring to inject method names to be invoked. Also event listening (wich is I believe a generic need) could be managed this way and benefit from some abstraction. con.pop(1) is probably the most frequently written line by every plugin developer, probably some abstraction (an event started with his thread and the fs event passed as an argument?) could make code more elegant 

On Fri, Sep 11, 2009 at 00:19, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[josh at radianttiger.com]

I've been having the same idea, except completely different. I'd probably start with StructureMap or MEF. I'm attracted to the idea of creating an alternative to mod_event_socket except using WCF as the transport, enabling both WS-* and Rest access into the FreeSWITCH core.


I think an effort to create a better archtecture in mod_managed is likely to get very religious very quickly. There's a _lot_ of difference of opinion in the .NET ecosystem. Just witness Michael and I disagreeing on something as simple as how to handle unhandled exceptions.


Instead of architecting a more complete solution, I think a good solution might be to de-architect the current solution to easily enable extensibility and component replacement. That way, each of us can have the high-level framework we want without disagreement on the low-level framework. This is the same model used in ASP.NET MVC, where it works well out of the box, but you can easily hook in and replace any chunk of it you want if your needs vary.


I started playing with a refactoring of the current managed.dll in order to make it more pluggable. It kinda got away from me....<grin>....I've published my code up on github at http://github.com/joshrivers/FreeSWITCH.Managed


The first thing I did was make it _really_ easy to make your own managed.dll. There's two basic points where managed code attaches to unmanaged code. If you rewrite the loader class, you can make your own managed.dll that does anything you want.


The next layer up exposes a simple IOC registry that could be modified to replace or add to the logging chain, the module loading chain, or the command execution chain.


Beyond that, appdomain loading, script compilation, and inside-appdomain plugin loading are all plugabble.


Current plugins should all remain compatible (mine at least haven't needed a recompile).


What needs to be done:
- There are a few changes in SVN that need to be integrated with my fork.
- A lot more unit testing would be useful.
- There should be a mechanism for indicating that a script or dll should be pre-loaded into all other appdomains (as a mechanism for defining new plugin types).
- There should also be a mechanism for loading a script or dll into the primary appdomain (to allow your code to modify the core operation of mod_managed without recompiling the dll)


Most of this should be simple, but I thought it was high time that I got some feedback. I think this model makes it possible to much more simply add new functionality to mod_managed allowing coders to establish their own plugin models and use frameworks such as StructureMap, Spring.NET, MEF, WCF, or Workflow to create their voip applications.


Let me know what you think,
Josh

On Fri, Sep 11, 2009 at 12:55 AM, Raffaele P. Guidi <raffaele.p.guidi@gmail.com (raffaele.p.guidi@gmail.com)> wrote:

[mgg at giagnocavo.net]

Hey nice to see someone interested in this – that’s a lot of files you have there, and looks like you put a lot of effort into it! I haven’t had time to look at it much, but here are a few initial impressions.

Right off the bat: there can be tons of cleanup and refactoring, no doubt about that. Much of the current code is to satisfy my needs in production, which it does very well. With that out of the way…

I’m a bit hesitant to go too far from the FreeSWITCH core as far as architecture goes. For instance, I’m not quite sure why’d we have our own managed logging subsystem that allows them to plug in other things that aren’t part of FS. Either they should use the FS logging system, or use their own such as log4net. Or perhaps I don’t see why we’d want this behavior.

Going away from the core as far as adding .NET specific features (like look at the static ManagedSession.Originate that takes hangup delegates, or the “nice” wrapper for Log (Write and WeiteLine, with an enum instead of a string) are keeping close to the core, just adding a tiny bit of API cleanup. FreeSWITCH exposes a lot of strings, and while maybe that’s important for some languages, .NET users are going to expect stronger typing. But I don’t think these types of things get people away from FreeSWITCH much.

Things like making a published SOAP interface for FS seem not really related to mod_managed. They can easily be done as 3rd party plugins, or convince the core FS team that exposing via SOAP via mod_managed is the way to go. Also keep in mind that the majority of users are on Linux, so that rules out WCF and some other fun stuff that only works on the CLR – I’d say it all has to work on Mono.

As for all the rest of it, can we talk interactively, perhaps with other users interested in mod_managed? Reading over your email, I think I’m not understanding many of the use cases that are being fixed.

Thanks a lot!
-Michael

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Josh Rivers
Sent: Wednesday, September 23, 2009 5:00 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET


I've been having the same idea, except completely different. I'd probably start with StructureMap or MEF. I'm attracted to the idea of creating an alternative to mod_event_socket except using WCF as the transport, enabling both WS-* and Rest access into the FreeSWITCH core.



I think an effort to create a better archtecture in mod_managed is likely to get very religious very quickly. There's a _lot_ of difference of opinion in the .NET ecosystem. Just witness Michael and I disagreeing on something as simple as how to handle unhandled exceptions.



Instead of architecting a more complete solution, I think a good solution might be to de-architect the current solution to easily enable extensibility and component replacement. That way, each of us can have the high-level framework we want without disagreement on the low-level framework. This is the same model used in ASP.NET MVC, where it works well out of the box, but you can easily hook in and replace any chunk of it you want if your needs vary.



I started playing with a refactoring of the current managed.dll in order to make it more pluggable. It kinda got away from me....<grin>....I've published my code up on github at http://github.com/joshrivers/FreeSWITCH.Managed



The first thing I did was make it _really_ easy to make your own managed.dll. There's two basic points where managed code attaches to unmanaged code. If you rewrite the loader class, you can make your own managed.dll that does anything you want.



The next layer up exposes a simple IOC registry that could be modified to replace or add to the logging chain, the module loading chain, or the command execution chain.



Beyond that, appdomain loading, script compilation, and inside-appdomain plugin loading are all plugabble.



Current plugins should all remain compatible (mine at least haven't needed a recompile).



What needs to be done:

- There are a few changes in SVN that need to be integrated with my fork.

- A lot more unit testing would be useful.

- There should be a mechanism for indicating that a script or dll should be pre-loaded into all other appdomains (as a mechanism for defining new plugin types).

- There should also be a mechanism for loading a script or dll into the primary appdomain (to allow your code to modify the core operation of mod_managed without recompiling the dll)



Most of this should be simple, but I thought it was high time that I got some feedback. I think this model makes it possible to much more simply add new functionality to mod_managed allowing coders to establish their own plugin models and use frameworks such as StructureMap, Spring.NET, MEF, WCF, or Workflow to create their voip applications.



Let me know what you think,

Josh


On Fri, Sep 11, 2009 at 12:55 AM, Raffaele P. Guidi <raffaele.p.guidi@gmail.com (raffaele.p.guidi@gmail.com)> wrote:
I want to move ILoadNotificationPlugin from being this “catch all” thing that controls the entire assembly to something that can be used to fire up code; effectively “OnLoad” and “OnUnload”. To dynamically control loading, we’ll probably reflect on the individual plugins looking for attributes or perhaps some sort of static load function.



I meant to do something like that probably using spring to inject method names to be invoked. Also event listening (wich is I believe a generic need) could be managed this way and benefit from some abstraction. con.pop(1) is probably the most frequently written line by every plugin developer, probably some abstraction (an event started with his thread and the fs event passed as an argument?) could make code more elegant

On Fri, Sep 11, 2009 at 00:19, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
Well, we have absolutely no idea what the background thread is doing. It might be critical, and the fix is trivial: put a try/catch on it. This is the model all .NET applications have. Background threads doing bad things should always take down the process.

However, that’s a good point about Load() failing. The approach taken is more or less how FreeSWITCH handles things in general now. If a module has an error, the switch just logs and goes on. I’m not really in favour of this, and suggested at least a “required” attribute in the modules.conf that would prevent the switch from loading if the module fails.

The fix is probably to create an attribute you can apply to the plugin classes that indicate what kind of failure handling you want. For the assembly, we’d add an attribute with an enumeration like:
- Default (scan, call ILoadNotificationPlugin, log errors if they occur)
- NoLoad (don’t load the assembly)
- Critical (stop the switch if there’s an exception during loading)

That’d provide the control you want for loading. We could do something similar for App/Api plugins.

I want to move ILoadNotificationPlugin from being this “catch all” thing that controls the entire assembly to something that can be used to fire up code; effectively “OnLoad” and “OnUnload”. To dynamically control loading, we’ll probably reflect on the individual plugins looking for attributes or perhaps some sort of static load function.

How’s that sound?


From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Thursday, September 10, 2009 12:48 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




I'm only concerned with the difference in treatment.

public class CrashFreeSWITCH : ILoadNotificationPlugin
{
public bool Load()
{
ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });
return true;
}
}
Crashes the entire switch, terminating all calls and disconnecting from the PSTN.
public class CrashFreeSWITCH : ILoadNotificationPlugin
{
public bool Load()
{
throw new NotImplementedException();
return true;
}
}

Logs a message to the console and doesn't load the module, while leaving the switch operating.



In my experience, exceptions in multi-threaded code: a) happen, b) are hard to diagnose. Is the best behavior for the environment to crash, providing no diagnostic information? That's hard in development, and even harder in production. I suppose 'terminate switch on fault' should be an option, to allow the operating system to restart the whole process on fault conditions, but if that is the intended result, shouldn't any fault do the same thing? What if the billing was happening in my second code block?



Normally, I'd trap the ThreadException and UnhandledExceptions in my application, so that my code could choose the correct actions to perform should the application get into an unknown state. This can include terminating the whole application, but also logging diagnostic information, trying to save uncommitted data, and sending notifications of the failure.



Is 'crash if it's a thread, but not if it's not' good because it's the way the module works now, or is it a better design for a reason I'm not understanding?



On Wed, Sep 9, 2009 at 11:09 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
Well, a segfault in voicemail would do the same thing.

Suppose your plugin runs a thread that does something important, like billing or so on. That thread fails – do you really want it to go on?

Anyways, the solution is simple enough, handle your exceptions J. Every plugin can decide what it wants to do here.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 10:41 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




The question is whether the CLR should take down the whole phone server due to an unhandled exception...definitely the CLR should terminate...but shouldn't it just log the exception to the console, not crash the core?
On Wed, Sep 9, 2009 at 6:30 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:
That’s by design. If a thread fails, and there’s no handler, then the application could be in a corrupted state, so the CLR takes down the process.

I think there is a .NET 1.0 compat switch you can enable in the config if you like exceptions to be silently ignored J.

-Michael

From: freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org) [mailto:freeswitch-users-bounces@lists.freeswitch.org (freeswitch-users-bounces@lists.freeswitch.org)] On Behalf Of Josh Rivers
Sent: Wednesday, September 09, 2009 6:39 PM

To: freeswitch-users@lists.freeswitch.org (freeswitch-users@lists.freeswitch.org)
Subject: Re: [Freeswitch-users] Subscribing to events in managed C# / .NET




I have a new thought on the crashes...I'm able to crash FreeSWITCH any time I like, just by having an exception in a thread.

public class CrashFreeSWITCH : ILoadNotificationPlugin

{

public bool Load()

{

ThreadPool.QueueUserWorkItem((o) => { throw new NotImplementedException(); });

return true;

}

}



Perhaps Application.ThreadException or AppDomain.UnhandledException need to be trapped?



On Wed, Sep 9, 2009 at 4:51 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[josh at radianttiger.com]

On Wed, Sep 23, 2009 at 7:31 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote: