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. Richard
-- _____________________________________________________________________ -- 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
