On Wed, Dec 4, 2013 at 12:45 PM, Joshua Colp <jcolp at digium.com> wrote: > Mark Michelson wrote: > >> The basic scenario where persistence is desirable is when Asterisk has >> accumulated a bunch of MWI state, then restarts, then a device requests >> current MWI state for a mailbox. If mailbox state is not persisted, then >> Asterisk has to respond with incorrect state. If the MWI state is >> persisted, then Asterisk can respond with the latest known state. >> > > Correct, until it's updated. > > > Regarding work required by the application, having state not be >> persisted is, in my opinion, more of a hassle. If Asterisk restarts, >> then the application needs to know that it happened and then retransmit >> all MWI state to Asterisk in order to repopulate Asterisk's cache. If >> state is persisted, then the only state that needs to be retransmitted >> by the application is whatever couldn't previously have been delivered >> during the downtime. >> > > The application would have a WebSocket connection up so it would know. > > > Regarding the mailbox destruction scenario, the application is going to >> have to create a backlog of updates to send at any point when Asterisk >> is down, whether those updates are changes to MWI state or creation or >> destruction of said state. I don't think that removing persistence will >> have any effect on this. >> > > If there is no persistence it actually simplifies things quite a bit > because you *don't* have to keep a backlog of updates. > > It boils down to: > When your connection to Asterisk is established feed it state for all > known about mailboxes > > If you have persistence you now have to: > Keep a log with any in-flight updates that received no response > Keep a log of any mailboxes that have been changed (added, updated, > deleted) > When your connection to Asterisk is established replay your log > * This should ensure state is the same between both > > Persistence does not require keeping a backlog because you could always flush the cache and repopulate it as if there were no persistence when you reconnect. In the mean time Asterisk can respond with what it knows. Also the link breaking does not necessarily mean that Asterisk restarted. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131204/2316b316/attachment.html>
