[asterisk-dev] Contacts, Contact Status and Sorcery

[Richard Mudgett]

On Thu, Apr 30, 2015 at 2:10 PM, George Joseph <george.joseph at fairview5.com>
wrote:

>
> Change https://gerrit.asterisk.org/261 sparked some discussion about
> contacts and contact status so I'd like to continue that here.
>
> 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.
>
> 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.
>
> 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.
>

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.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/3284aca8/attachment.html>