Re: [log4perl-devel] Config file reload on signal

[Wiggins d'A. <wi...@da...>]

msc...@ao... wrote:
> Hey,
> 
> just had an idea: How about if we add functionality to init_and_watch in Log::Log4perl to not only watch config files but to also be able to listen to (Unix) signals instead? Yeah, yeah, I know signals are unreliable and can cause all kinds of crazy stuff -- but how about if we have the signal handler just set a global variable, which is checked by the watcher code instead of calling time() all the time?
> Please take a look at the patch below, and let me know what you think ... the addtl. syntax is:
> 
>    init_and_watch($file, 'HUP'); # will listen to SIGHUP
> 
> I've also attached a test file.
> 

I like the idea but I think this goes back to the notion of 
init_and_watch calling die on failure. So two quick questions,

1) Is it possible to store the current config, load the new one, and 
rollback to the previous one if something goes wrong?

2) Is it possible to compartmentalize the config reading+updating, etc. 
code to the extent of rather than passing init_and_watch a signal to 
catch, that a particular class method could be called instead, then the 
user could install their own signal handler easy enough.  (Or maybe both 
cause if you can do #2, then it should be trivial to have init_and_watch 
accept a signal and it would just set the call to the class method to 
that signal for the user).

Currently I am using Log4perl extensively in a POE framework app (by the 
way it works beautifully, well with the exception of FileRotate but I 
think an upgrade will improve that situation) so I already have a 
framework for handling events and signals, but it would be nice if I 
could control the reloading of the config file on my own, rather than 
having init_and_watch do it for me either through a time based or a 
signal based mechanism. Because I have a 24/7 running app as well, I 
don't want to have the worry of sending a signal to the app or even 
after a certain amount of time, having it caught and having it 'die' on 
me when that isn't the type of signal I sent.  This essentially gets 
somewhat back to being able to pass a callback to the init_and_watch so 
that when it fires, certain actions can be taken.

I realize this is open source, and that I should put my keyboard where 
my mouth is but I am still a little intimidated by taking this on my own 
especially without being familar with the Log4perl internals (yet!), but 
these are just some ideas I have mulled over while writing our app. 
Given enough time I will probably get around to taking a stab at it 
myself, but if Mike or Kevin, et al. have a way to work it in while all 
of this is fresh I think it would be a nice addition.  I also realize 
there is the log4j standards, etc.

Just my $.02 for what their worth...

http://danconia.org