On Thu, Apr 30, 2015 at 1:28 PM, Richard Mudgett <[email protected]> wrote:
> > > On Thu, Apr 30, 2015 at 2:10 PM, George Joseph < > [email protected]> 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.
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
