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.
--
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
