On Thu, Feb 5, 2015 at 6:38 AM, Ben Merrills <b.merrills@xxxxxxxxxxxxxxxx> 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. >> >> > 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". >> I'm tending to agree with Ben here. If you app has lost the connection to asterisk, then the message are gone. If you want to ensure the messages are delivered, then some sort of ACK system should be in place. However, like Ben, I don't think this is the job of Asterisk; message bus, maybe. That's what we do. Now, something I don't think asterisk does, is some sort of event storage system. When asterisk fires an event over the WS, there should also be a collector taking the events and dumping them into DB, file, etc. That way, if an application needs to review the history of events, they are logged some place. Again, this is what I do. I pushed an event to a message bus, then the collector at the far end processes the event. Both stores a copy into a local DB, and published the event over a WS. While it is complicated and a lot of moving parts, I don't think I would want asterisk to do this work. I would rather have it externalized in some fashion. Again, my thoughts and what has been working well so far. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
