[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

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.

Josh's Sorcery Caching proposal triggered another idea though.  What if we
created a layer, similar to the cache, that allowed in-memory changes that
don't persist.   I.E.  calling ast_sorcery_create_temp instead of
ast_sorcery_create would create the object only in memory and not attempt
to persist it to any other back-end.  When asterisk restarts, you have the
original versions.

Scenario:

We get rid of contact_status and add those fields to contact.   When a
dynamic contact registers, we call ast_contact_create and it gets persisted
like today.  When it's status changes, we update the contact with
ast_contact_update_temp which stays in memory only.  When a contact
de-registers, we call ast_sorcery_delete and it gets removed from both
memory and astdb.  When asterisk restarts, we get only the remaining
persisted objects.

For permanent contacts, we do the same except we call
ast_sorcery_create_temp and ast_sorcery_delete_temp so they never get
persisted to astdb.

Now we have a single consistent way to manage contacts without the need for
separate status.

This could easily apply to a config file based back-end as well.  In fact,
with this proposal, a good chunk of res_pjsip_config_wizard goes away.  The
bottom half of that program creates memory wizards for the generated
objects and inserts the wizards into the object type's wizard chain.  It
also required some module dependencies I'm not proud of.   With the new
capability, the config_wizard could add pjsip objects at any time and not
require that it be loaded before res_pjsip.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/27cc5309/attachment.html>