suggestions for dynamic run-time configuration?

[E R <pc...@gmail.com>]

I was wondering if anyone had suggestions / recommendations for a
run-time application configuration mechanism for mod-perl apps. What I
am thinking of is simply a way to communicate new application settings
to all of the mod-perl children.

The only solution I can think of is to have all of the mod-perl child
processes periodically check a file to see if it has changed, and if
so have the child process reload their application configuration. By
"application configuration" I mean configuration data at the
application level and above - not necessarily httpd-level
configuration data (i.e. such as found in httpd.conf.) Typical
application configuration data includes database credentials, flags to
enable/disable parts of the application, urls for web services used by
the application, etc. The idea is to have a capability something like
Facebook's Gatekeeper as described in one of their tech talks (
http://techcrunch.com/2011/05/30/facebook-source-code/ )

To reduce the impact this checking would have on serving requests I
was thinking of checking only every N requests (i.e. N = 10) and/or
performing the check as part of the cleanup handler.

Any suggestions / recommendations or alternatives for a mod-perl environment?

Re: suggestions for dynamic run-time configuration?

[E R <pc...@gmail.com>]

2011/11/1 Torsten Förtsch <to...@gmx.net>:
> On Monday, 31 October 2011 22:28:32 E R wrote:
> ...
>> Any suggestions / recommendations or alternatives for a mod-perl
>> environment?
>
> Have a look at MMapDB on CPAN. ...

That's a very interesting module - thanks for the pointer!

Re: suggestions for dynamic run-time configuration?

[Torsten Förtsch <to...@gmx.net>]

On Monday, 31 October 2011 22:28:32 E R wrote:
> To reduce the impact this checking would have on serving requests I
> was thinking of checking only every N requests (i.e. N = 10) and/or
> performing the check as part of the cleanup handler.

I wouldn't do that. Suppose your server is under load so that N workers 
are needed. Then the load drops so that M workers are needed where M<<N. 
Depending on your config N-M workers may linger on for quite a while not 
getting any request. Now you change the config. If you check only every X 
request cycles for an update the new config may take a long time to make 
it to all the workers.

> Any suggestions / recommendations or alternatives for a mod-perl
> environment?

Have a look at MMapDB on CPAN. It maps a (prepared binary) file read-only 
into RAM. Thus, the memory is shared among all of it's clients. Access is 
similar to hash/array lookup in Perl. Updates replace the whole file and 
set a flag in the header of the old file that may still be mapped by a 
number of clients marking the DB as invalid. Checking if there is new 
config is hence a simple RAM lookup, no syscall or similar. Only if the 
flag indicates the currently mapped DB is out-dated further steps are 
taken to map the new one. The DB file itself is organized to allow for 
binary search. So, lookup is quite fast. If you store larger chunks of 
data another feature comes in handy. Upon access data is not copied. What 
you get is a read-only variable (a PV) that points directly to the shared 
memory. If you pass around references in your program then this value 
will never be copied. There is one more thing, the DB stores also the 
utf8 flag for its data. So, the strings C<do{use bytes; "förtsch"}> and 
C<do{use utf8; "förtsch"}> are stored as 2 different things and you get 
them out as such.

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net