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 -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org
