<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 12:45 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">Mark Michelson wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The basic scenario where persistence is desirable is when Asterisk has<br>
accumulated a bunch of MWI state, then restarts, then a device requests<br>
current MWI state for a mailbox. If mailbox state is not persisted, then<br>
Asterisk has to respond with incorrect state. If the MWI state is<br>
persisted, then Asterisk can respond with the latest known state.<br>
</blockquote>
<br></div>
Correct, until it's updated.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regarding work required by the application, having state not be<br>
persisted is, in my opinion, more of a hassle. If Asterisk restarts,<br>
then the application needs to know that it happened and then retransmit<br>
all MWI state to Asterisk in order to repopulate Asterisk's cache. If<br>
state is persisted, then the only state that needs to be retransmitted<br>
by the application is whatever couldn't previously have been delivered<br>
during the downtime.<br>
</blockquote>
<br></div>
The application would have a WebSocket connection up so it would know.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regarding the mailbox destruction scenario, the application is going to<br>
have to create a backlog of updates to send at any point when Asterisk<br>
is down, whether those updates are changes to MWI state or creation or<br>
destruction of said state. I don't think that removing persistence will<br>
have any effect on this.<br>
</blockquote>
<br></div>
If there is no persistence it actually simplifies things quite a bit because you *don't* have to keep a backlog of updates.<br>
<br>
It boils down to:<br>
When your connection to Asterisk is established feed it state for all known about mailboxes<br>
<br>
If you have persistence you now have to:<br>
Keep a log with any in-flight updates that received no response<br>
Keep a log of any mailboxes that have been changed (added, updated, deleted)<br>
When your connection to Asterisk is established replay your log<br>
* This should ensure state is the same between both<div class=""><div class="h5"><br></div></div></blockquote><div><div><br>Persistence does not require keeping a backlog because you could always flush the<br></div>cache and repopulate it as if there were no persistence when you reconnect.  In the<br>
mean time Asterisk can respond with what it knows.  Also the link breaking does not<br>necessarily mean that Asterisk restarted.<br></div></div><br></div><div class="gmail_extra">Richard<br></div></div>