[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

On Thu, Apr 30, 2015 at 1:28 PM, Richard Mudgett <rmudgett at digium.com>
wrote:

>
>
> 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.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/f3115b9f/attachment-0001.html>