[asterisk-app-dev] ARI ApplicationActivated event?

Ben Merrills b.merrills at mersontech.co.uk
Thu Feb 5 06:28:33 CST 2015


> Ben Merrills wrote:
> >> Kevin Harwell wrote:
> >>
> >> <snip>
> >>
> >>> So then there are for sure cases where full state is not recoverable
> >>> and a missed message(s) playback mechanism would be ideal. I guess
> >>> the questions go back then to how useful is it and is it worth the
> >>> effort?
> >> I think, depending on the application, it's useful.
> > [skrusty] I think the approach here is wrong. Asterisk shouldn't be
> > buffering these messages or worrying messages have not been received
> > (as such). When we reviewed (with some other community members)
> > improving reliability and fault tolerance, the main strategy seems to
> > be queue those messages and distribute them over multiple applications
> > serving ARI.
> >>> Right now Asterisk doesn't even notify an application that it is in
> >>> a "reactivated" state.  So either applications currently built on
> >>> ARI don't care about syncing state on reconnection, or they use the
> >>> current commands available to do it (and that is sufficient).  Maybe
> >>> having the proposed extra notification would not be so useful.
> >> I think right now this hasn't been run into enough to really be a
> >> substantial problem for people.
> > [skrusty] True, it's not, but it has been considered. The idea of
> > proxying those messages from a locally hosted service into a queue of
> > some sorts seems to work best so far. This method solves issues
> > dealing with high availability and failover.
> 
> This isn't trying to solve high availability and failover. As you've said there are
> ways to do that. This is "I have a standalone application. It crashes and
> restarts. I had channels in it. How do I recover?". As it is those channels are
> lost to the application but still remaining up, unless the application maintains
> its own state. That's a bad spot to be in. IMO saying to deploy an external
> message bus with a proxy and to persist state in an outside mechanism is not
> a very good answer to that for people who are trying to do simple things.
> 
> Maybe the solution is that upon reconnection if any channels remain in the
> application you get an event with their ids. This reduces how much the
> application has to do (and in fact if they don't want to store state they can
> hang them all up and start fresh). It's also information we already have.
> 
[skrusty] Could you not just do that already by getting all channels and looking for the ones who have the app set as Stasis and appArgs as your application? 
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
> 
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5646 / Virus Database: 4281/9060 - Release Date: 02/05/15



More information about the asterisk-app-dev mailing list