|Summary:||ASTERISK-18842: text config files are treated as unchanged when changing and reloading them quickly one after another|
|Reporter:||Thomas Arimont (tomaso)||Labels:|
|Date Opened:||2011-11-09 09:35:06.000-0600||Date Closed:|
|Versions:||184.108.40.206 220.127.116.11 13.18.4||Frequency of|
|Description:||Text config files are (can be) treated as unchanged when changing a config file and reloading it ('reload' or module reload) quickly one after another. Due to the generic implementation of the configuration loading, which was introduced somewhere in Asterisk 1.6 to increase performance, a text config file is treated as unchanged in dependency of the file modification time (to avoid unnecessary config parsing). Since the granularity of this timestamp is 1 sec fast consecutive config changes incl. reloading within this time are mostly not succesful. I've spent some time to find out what was wrong with a config script of mine ...|
Is there no smarter way to solve this?
|Comments:||By: Walter Doekes (wdoekes) 2011-11-09 13:42:46.662-0600|
There might be smarter ways to do it (e.g. more granularity). But I would rather fix the problem that causes you to have to reload a config every second. Config reloading can be quite an expensive operation. Perhaps there are cheaper ways to accomplish what you want.
By: Thomas Arimont (tomaso) 2011-11-09 14:27:08.616-0600
yes, indeed config loading every second would not be a meaningful thing and that's not what we are really doing.
There is one special case in our 'configurator surrounding' where we have to change a config, reload, change the config again and reload it another time. It's regarding the app_queue resp. the queues.conf configuration file:
We use dynamic queue members (exclusivly) and generally want to have them persistent even after a reload (using persistentmembers parameter). The members use a special feature code to log in resp. log out which triggers the queue add or queue remove dialplan functions. However if the config-admin wants to delete a certain member from the queue (so the member is not able to login anymore), we first have to set the queues.conf persistentmember parameter to no, reload, set the queues.conf to what it was before and reload again - to get what we want.
If you have another good solution for this special problem you are welcome!
(The solution which we are using now to get this work with asterisk 1.8 - asterisk 1.4 was fine - is to use a pause of 1 second before rewriting the config a second time, but infact I would like to have these things going faster to approach more 'realtime configuration' - maybe I'm a little bit too perfectionistic)
By: Leif Madsen (lmadsen) 2011-11-10 15:21:50.163-0600
Can you elaborate on why you need to change persistentmembers at all in order to log someone out?
By: Thomas Arimont (tomaso) 2011-11-14 01:45:52.752-0600
it might be a more 'historical' way how we implemented the (config) handling of queues and call groups:
Generally our config-admin is able to configure waitqueues and can define the members which are allowed to login via feature code. If he wants to remove a member later setting persistentmembers to no, reloading and restoring the old queues.conf (plus reloading) seems to be the only way to get rid of the persistence of this member.
Beside this special problem, we cannot really exclude the case that config changing and reloading is done quickly one after another. This is because a user (e.g. activating/deactivating call forwarding) as well as the config admin can change resp. initiate a config reload process independently. If the config change/reload process is quick enough and both processess occur almost at the same time this could make a problem too. Indeed our config change/reload process is usually taken more than one second, so this problem has not been seen yet.
It might be an enhancement if at least the file size of a config file additionally is taken into account when examing if a file has changed or left unchanged.
By: Walter Doekes (wdoekes) 2011-11-14 02:11:52.303-0600
> Beside this special problem [...] a user (e.g. activating/deactivating call forwarding) as
> well as the config admin can change resp. initiate a config reload process independently.
> If the config change/reload process is quick enough and both processess occur almost at the
> same time this could make a problem too. Indeed our config change/reload process is usually
> taken more than one second, so this problem has not been seen yet.
While I understand that it'd be easiest for you to have it fixed at this level; I would argue
that you might need a layer between your config altering process and the process of telling
the new config to asterisk. (If i-already-updated-the-config-this-minute then wait-a-bit and
first then update-the-config.)
By: Thomas Arimont (tomaso) 2011-11-14 02:26:13.838-0600
yes, your suggested solution is what we will finally have to do (resp. have already done) to avoid problems with this changed behaviour of asterisk 1.6. Thanks a lot for you interest in this issue.
Regards from Aachen/Aken
By: Matt Jordan (mjordan) 2011-11-15 09:16:43.777-0600
Changing this issue from bug to feature request. The fact that config files are tracked as being modified using timestamps with a 1 second granularity is part of the design, and is not a bug. Changing the design to using a different mechanism would be a new feature for Asterisk.