On Tue, Feb 3, 2015 at 6:47 PM, Joshua Colp <jcolp@xxxxxxxxxx> wrote:
Hmm now that I think about it, once all refs to the app goes away it will be destroyed. Upon reconnect it is not 'activated' but considered a new app. If we decide to put this in, my current opinion would be to keep it simple and just send a notification that the app was activated and whether or not it missed any messages. Then the app can retrieve any current state it might need to update itself with. This puts it in a position of knowing the current state which is consistent with when the app reconnects but is created new.
Kevin Harwell wrote:
Greetings,
Kia ora,
I was thinking of adding a new "ApplicationActivated" event to ARI that
would be raised upon a websocket reconnecting and an application being
made active again. Currently, I am thinking it will just contain a count
of the number of messages that were missed while the websocket was
disconnected.
Do we provide enough access to rehydrate the application upon the case where messages were indeed missed?
I lean toward yes, but it probably is application dependent.
If a new channel starts the application do we currently reject that, or do we accept it? If we accept it how does the newly reconnected/connected application know that channel is in it?
Upon disconnection from the websocket an application goes into the "inactive" state. From what I can tell attempts to create new channels are rejected. Even if that is allowed the application could retrieve a list of channels upon reconnect.
I think ultimately best practices and documentation about how to deal with this are equally as important as further information.
Pondering a bit I can see applications wanting Asterisk to handle this in different ways:
1. Tell me that I'm taking over an application that is still active
This already happens with the 'ApplicationReplaced' event.
2. In case of disconnection buffer the last N messages and provide them to me in order when I reconnect
This could make sense. However, this worries me a bit in that the buffer could potentially grow quite large (large interval between reconnect or they don't reconnect at all). Also I lean a bit toward having the application be responsible for choosing what information they deem important and then issuing commands for updates as opposed to Asterisk spamming them with a bunch of messages. On the other hand, I could see how it would be important to know all state transitions that took place and not just the current state.
3. Disconnect all channels upon application disconnection and don't accept new ones
Rejecting new ones makes sense, but disconnecting current ones seems overly aggressive. I can't see applications wanting calls being hung up mid conversation just because the application is disconnected for a time.
Thoughts?
Hmm now that I think about it, once all refs to the app goes away it will be destroyed. Upon reconnect it is not 'activated' but considered a new app. If we decide to put this in, my current opinion would be to keep it simple and just send a notification that the app was activated and whether or not it missed any messages. Then the app can retrieve any current state it might need to update itself with. This puts it in a position of knowing the current state which is consistent with when the app reconnects but is created new.
--
Kevin Harwell Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
