> On Dec. 17, 2014, 1:51 p.m., Mark Michelson wrote:
> > I think the key for me understanding and accepting this change is to
> > decipher why:
> >
> > "When the module is loaded again, a reload of res_pjsip is triggered which
> > causes the observer to do a reload as opposed to a load of the file"
> >
> > this happens. Why does a reload of res_pjsip cause the observer to perform
> > a reload instead of a load?
>
> George Joseph wrote:
> Well, res_pjsip can't (practically) be unloaded right? So all it knows is
> reload. If you call reload on res_pjsip, it calls load on all object types
> for all wizards with the reloaded flag set. That's correct.
>
> Meanwhile, if the res_pjsip_config_wizard module has been unloaded and
> then loaded again, it's starting fresh and empty. It then calls reload on
> res_pjsip to trigger the construction of all the objects. res_pjsip then
> does it's thing and calls load w/ reloaded on all the wizards. Now the
> res_pjsip_config_wizard object_type_loaded observer gets called with the
> reloaded flag set. This sets the FILEUNCHANGED flag in the config load which
> returns FILEUNCHANGED so no ob jects get created. This happens because
> config has cached the mtime of the pjsip_wizard.conf file and saw no change.
>
> In order for this to work, when res_pjsip_config_wizard unloads, it has
> to clear the config mtime cache for pjsip_wizard.conf. When it loads again,
> config load will not find it in the cache and return a valid config even
> tough the FILEUNCHANGED flag was set.
>
>
>
> Mark Michelson wrote:
> Thanks for the explanation. My thought on this is that
> res_pjsip_config_wizard shouldn't necessarily translate the fact that
> pjsip.conf was reloaded to mean that pjsip_wizard.conf also needs a reload.
> The two config files are managed by separate modules, and the fact that one
> module reloaded its config doesn't necessarily translate to mean that the
> other module should be reloading its config. res_pjsip_config_wizard should
> be performing a load operation instead if it has not previously loaded the
> config file. Since you're already maintaining state of the previous config in
> the object_type_wizard struct, would it not make sense to use its presence to
> know whether you should set CONFIG_FLAG_FILEUNCHANGED? Something like:
>
> if (otw->last_config) {
> ast_set_flag(&flags, CONFIG_FLAG_FILEUNCHANGED);
> }
>
> My main reason for trying to keep the change within
> res_pjsip_config_wizard.c is that I don't like the idea of exposing internals
> of the config system for just one use case in the whole of Asterisk unless it
> is absolutely necessary. Exposing the ability to clear a file from the cache
> doesn't really make sense when there's already a method of loading a file
> without caring about what the cache currently contains.
It's not looking at pjsip.conf at all and res_pjsip_config_wizard has gone away
completely so it can't save any state. I suppose that when it loads I can do a
config load for each object type with a NOCACHE flag, then just destroy the
config. I think that clears the mtime cache. That's a kludge though for the
fact that you can't clear the config cache. Once the wizard loads though, it's
res_pjsip that controls when the wizard loads its objects.
- George
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4276/#review13998
-----------------------------------------------------------
On Dec. 17, 2014, 10:24 a.m., George Joseph wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4276/
> -----------------------------------------------------------
>
> (Updated Dec. 17, 2014, 10:24 a.m.)
>
>
> Review request for Asterisk Developers and Joshua Colp.
>
>
> Repository: Asterisk
>
>
> Description
> -------
>
> The earlier patch fixed the test breakage but caused a problem when
> res_pjsip_config_wizard is unloaded then loaded again.
>
> When res_pjsip_config_wizard is unloaded, config still has the mtime of
> pjsip_wizard.conf cached. When the module is loaded again, a reload of
> res_pjsip is triggered which causes the observer to do a reload as opposed to
> a load of the file. The result is FILEUNCHANGED and the wizard never loads
> any objects. The file has to be cached for normal operation so the easiest
> solution was to expose the config cache_remove function and call it when
> res_pjsip_config_wizard is unloaded. Now if res_pjsip_config_wizard is
> loaded, it gets a good config instead of FILEUNCHANGED even though it's a
> reload.
>
>
> Diffs
> -----
>
> branches/13/res/res_pjsip_config_wizard.c 429698
>
> Diff: https://reviewboard.asterisk.org/r/4276/diff/
>
>
> Testing
> -------
>
> Tested the unloading and re-loading of the module as well as config reload
> and pjsip reload to make sure the correct objects were updated.
>
>
> Thanks,
>
> George Joseph
>
>
--
_____________________________________________________________________
-- 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
