> 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. > > > However as applications become more complex the need may arise for an > > application to know it is in a "reactivated" state and that things > > were happening while it was away. So should we implement it at all? > > Are disconnects a real problem? Do we do it now or later? > > I think sudden application termination is a problem. Controlled shutdown is > possible if the application is written to do it. > > > if the answer is "yes do it now!" then it becomes how do we implement > > it? What kind of information is enough for the majority of application > > use cases? > > So - I think it depends on the application itself. Whatever is done in Asterisk > can't completely cover the case of a restarting application in all cases. The > application is most likely going to have its own state that it'll have to persist. > This can get complex. Take the case where something doesn't want to do > this. It wants to start fresh. Any active channels be darned! Right now I don't > think that's even possible to achieve. > > The gist being... this is complicated. > > Geez how many times can I say "I think". > > -- > 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@xxxxxxxxxxxxxxxx > 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 _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
