[Freeswitch-users] Subscribing to events in managed C# / .NET

Josh Rivers josh at radianttiger.com
Thu Sep 10 11:47:39 PDT 2009


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 at 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 at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Josh Rivers
> *Sent:* Wednesday, September 09, 2009 10:41 PM
>
> *To:* freeswitch-users at 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 at 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 at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Josh Rivers
> *Sent:* Wednesday, September 09, 2009 6:39 PM
>
>
> *To:* freeswitch-users at 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 at giagnocavo.net>
> wrote:
>
> >Looks like the event object goes straight to pinvokes, so a null result
> just crashes?
>
>
>
> If it’s null, you should get a NullReferenceException. The C# compiler
> should callvirt the property getter and that’ll do a null check. If that
> isn’t happening, that’d be an interesting optimization somewhere along the
> line.
>
>
>
> -Michael
>
>
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Josh Rivers
> *Sent:* Wednesday, September 09, 2009 3:01 PM
>
>
> *To:* freeswitch-users at lists.freeswitch.org
>
> *Subject:* Re: [Freeswitch-users] Subscribing to events in managed C# /
> .NET
>
>
>
> A new discovery:
>
>         public bool Load()
>
>         {
>
>             ThreadPool.QueueUserWorkItem((o) =>
>
>             {
>
>                 Log.WriteLine(LogLevel.Notice, "Thread Starting. ");
>
>                 EventConsumer con = new EventConsumer("all", "");
>
>                 while (true)
>
>                 {
>
>                     Event ev = con.pop(0);
>
>                     if (ev == null) continue;
>
>                     Log.WriteLine(LogLevel.Notice, "Event: " +
> ev.serialized_string);
>
>                 }
>
>             });
>
>             return true;
>
>         }
>
> Does not crash. (Adding the null check prevents crash.) The backgrounded
> loop runs fine. Looks like the event object goes straight to pinvokes, so a
> null result just crashes?
>
>
>
> I like the idea of a 'startup-script' for mod_managed. It would also be
> excellent if there was an event or message  informing the background code to
> terminate nicely when the module reloads.
>
>
>
> --Josh
>
>
>
> On Wed, Sep 9, 2009 at 12:57 PM, Jeff Lenk <jlenk at frontiernet.net> wrote:
>
>
> 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 at giagnocavo.net>wrote:
>
> >  Hi,
> >
> >
> >
> >                 Can you please elaborate on the crash you receive when
> you
> > queue a thread during load?
> >
> >
> >
> > Thanks,
> >
> > Michael
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Subscribing-to-events-in-managed-C-NET-tp3573619p3613195.html
> Sent from the freeswitch-users mailing list archive at Nabble.com.
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090910/e8927667/attachment-0002.html 


More information about the FreeSWITCH-users mailing list