in reply to Config parsing module for mod_perl app?

First, what you're doing now sounds fine. I don't see why it needs to be a tied hash rather than a normal one, but the concept is fine.

If you do want to switch to something new, don't bother looking for a config parser that will watch for changes: there are none. Find one that supports a syntax you like, and then add the mod_perl specific stuff yourself.

All you need to do is put in a cleanup handler that will stat the config file and then call your config parser again if it changes. You can keep track of the last time you read it in a global variable. If you don't want to stat every time, you can keep track of the last time you did a stat, and only stat again if it's five minutes later.

  • Comment on Re: Config parsing module for mod_perl app?

Replies are listed 'Best First'.
Re: Config parsing module for mod_perl app?
by jehuni (Pilgrim) on Mar 27, 2002 at 18:42 UTC

    I assume that you suggest a cleanup handler since it runs after a request, so the user sees no performance hit, but correct me if I'm wrong, please. And the reason that I'm in favor of moving to a CPAN module was an attempt to make the code more modular and maintainable. (And, yes, my use of a tied hash is probably unnecessary. :-)

    (While mulling this over, I thought of the following idea, but maybe it's overkill. Use Apache::Reload with PerlSetVar ReloadAll Off. Then, use PerlSetVar ReloadModules to explicitly register my config-reading module. However, then I PerlSetVar ReloadTouchFile to the name of the config file. That should have the effect of only reloading my config-reading module whenever the touch file changes, and since the touch file will be the config file itself, that should have the desired effect.)

    So, anyway, I've got some good ideas to work with. Thanks to those who replied. I'm still left with one question, though: what's the lightest weight yet reliable config-parsing module out there? And one that properly handles file locking in case of multiple concurrent requests, as well?

    -jehuni

[reply]
      Yes, right about the cleanup handler.

      Your Apache::Reload idea sounds fine, but the code to stat a file and run your config parser again is awfully simple so don't be afraid to just write it.

      I don't think there's much difference between the config modules in terms of reliability (it's a fairly simple task), but for determining memory footprint I think you will just have to load them into memory to see. Larger files usually lead to more memory, unless the file is mostly POD.

      Don't worry about file locking. When you want to update your config file, just do it with a rename, i.e. mv myconfig.conf.new myconfig.conf. That should be an atomic update.

[reply]
[d/l]

In Section Seekers of Perl Wisdom