[PEAK] runIni => ZConfig revisited

Phillip J. Eby pje at telecommunity.com
Fri Nov 14 14:11:53 EST 2003


At 09:02 PM 11/14/03 +0200, alexander smishlajev wrote:
>Phillip J. Eby wrote, at 14.11.2003 20:30:
>
>>>one of the biggest problems for us now is the requirement to restart the 
>>>application upon any change in configuration file.  we have a strong 
>>>need to reload config files on the fly, restarting or updating only 
>>>those components that have their configuration changed.
>>Perhaps you could create a top-level component that holds the entire 
>>configured subtree, and simply discards/reloads it when necessary.
>
>i hope we will end with something like this, only on per-section basis: 
>when config section changes, we discard and reload the component whose 
>configuration is changed.
>
>perhaps we should keep track of file timestamps for all (or at least often 
>changed) sections and things made from these sections.

Well, you certainly could change settings or replace components on demand, 
as long as you don't have references to the objects spread far and wide, or 
other components don't depend on values provided by the changed components.


>>(I'm assuming here that the issue with restarting is that Python startup 
>>and module importing is too slow, not that recreating the app's component 
>>tree is a problem.)
>
>no.  the problem is that our application (server) operates with many 
>instruments simultaneously.  when configuration is changed for one 
>instrument, we should not stop instruments that are not affected.

Then, your top-level config should be for the server itself, and then it 
should have an explicit component model for adding, removing, and 
restarting instrument components, rather like J2EE containers have 
"deployment descriptors" for applications, that can then be started, 
stopped, etc.

Without knowing more about your app it's hard to suggest a more detailed 
architecture, but I do think your components need to be "lifecycle aware", 
so that they can start, stop, or reload.  Your top-level app can then 
schedule periodic checks for whether their configs are up-to-date, or use 
file change notifications if you have access to that sort of thing on your 
target platform.




More information about the PEAK mailing list