<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 1:28 PM, Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=rmudgett@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">rmudgett@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 2:10 PM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=george.joseph@fairview5.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">george.joseph@fairview5.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>Change <a href="https://gerrit.asterisk.org/261" target="_blank">https://gerrit.asterisk.org/261</a> sparked some discussion about contacts and contact status so I'd like to continue that here.<div><br></div><div>Today, dynamic contacts (incoming registrations) are created on the fly as full sorcery objects and stored in an astdb back-end so they survive a restart.  Permanent contacts however, are created on the fly as sorcery objects when the aor is created but instead of being managed by sorcery, are stored in an aor-specific container. Contact statuses for both types of contacts are created as full sorcery objects and stored in a memory back-end.  They obviously do not survive a restart.  This makes navigating the life-cycle of these objects a little convoluted.</div><div><br></div><div>The handling of dynamic contacts is pretty straightforward and I have no issue there.  Permanent contacts are another matter however.  Because they aren't managed by sorcery, none of the sorcery life-cycle observers get called and you can't retrieve them by id from sorcery like you can for dynamic contacts.  When you're dealing with contacts in general, you have to understand and account for that.   So, my first suggestion is that we treat the permanent contacts exactly as dynamic ones.   I.E.  They become fully-managed objects and get stored in the astdb with a flag or their expiration set such that when asterisk reloads, they get immediately expired.  They'll then be immediately rebuilt as the aors are parsed.  We can then get rid of the aor-specific containers and the processing around them.  </div><div><br></div><div>Contact status is also pretty straightforward but there's one minor complication related to the fact that status is mutable and sorcery objects can't be...  So although status is backed up by a memory wizard (which is just an ao2_container), in order to update the status you have to clone the object and replace the original object with the new one (well, you don't have to but Josh gets upset if you don't :)).   It's easy enough but it's also extra code and an opportunity for reference leaks.   My proposal here is that we modify the memory wizard such that if the sorcery_update method is called, we compare the object reference passed in with the object reference we have in the container and if it's equal, we just noop.  You still need to call ast_sorcery_update to trigger the observers but at least you don't have to clone the object anymore.   </div></div></blockquote><div><br></div><div>The sorcery objects are immutable so you don't need a lock on the object.  If they become mutable you will need a lock and all the nasty locking issues that entails.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div></div></div></div></blockquote><div><br></div><div>True but that's a policy not enforced by code and contact status doesn't need that "assistance".   Of course, updating an object hydrated from a serialized back-end certainly doesn't cause the update to be persisted and the config back-end can't persist anyway.   But for the scenario I described it would be perfect.</div><div><br></div></div></div></div>