Ceki, > >This concludes the Watchdog/Reconfigurator nickel tour. > Please do not bump > >your heads on the way out and watch that first step. > Comments are welcome > >as always. Once it looks like anyone that is going to > comment has, I will > >clean up the code, apply the suggestions, and start checking > code into cvs. > > Good. Are you going to check in under o.a.log4j,config?
Yes, unless I hear otherwise. > I think watchdogs should know the LoggerRepository they should > configure which something missing in the current design. Yes, I think you are right. I'll have to look at adding this. > Here is a config file messing with a watchdog: > > log4j.watchdog.name= W1 > log4j.watchdog.class=org.apache.log4j.config.HTTPWatchdog > log4j.watchdog.url=htpp://host/path/ > log4j.watchdog.checkInterval=60000 > log4j.watchdog.command=[start|stop] > > log4j.rootLogger=.... > > A Configurator will not *reconfigure* an already running watchdog > except to change its check interval or to stop it. To change the > watchdog, you rename it. Hm. So, you mean to treat Watchdogs like Loggers in the sense that there is only one instance at a time? I'll have to think about this. What about removing inactive Watchdogs, etc? Also, might it be a bit limiting to not allow reconfiguration of watchdogs via config files. I actually experimented with this a little bit. I had a configuration algorithm that looked like this: (there was a single watchdog repository/registry that allows stopping/removing all active watchdogs to make this work) - watchdog decides to reconfigure, creates and calls the configurator from its thread - configurator, at start of reconfiguration, stops and removes all active watchdogs, one of which is watchdog that called the reconfigure. - configurator configures as now, collects set of watchdogs for the new configuration. - after configuration is completed, configurator adds and starts all of the new watchdogs, exits. - original watchdog exits reconfigure, finds that it has been stopped, and stops. The catch was that the configurator had to be somewhat intelligent about the whole process. And maybe some other issues I am unaware of. It was also difficult to guarantee that the watchdog repository "owned"/referenced all of the active watchdogs. > I think watchdogs should know the LoggerRepository they should > configure which is something missing in the current Watchdog design. Maybe the watchdogs should live with the repository they are configured for. If we have a single WatchdogRepository, what happens with 2 watchdogs with the same name but for different repositories? > > Now that I think of it a bit more, I wonder if it is not better to go > the java.util.Timer route and view checks for file changes as > TimerTasks. This might not make sense until we start messing with time > sensitive appenders that send at most one email message per hour, one > SMS message per hour, etc. (SMS is a very popular messaging systems > for mobile phones based on the GSM technology.) Having a single point > for scheduling time sensitive events might prove to be very useful. > (It is not hard to rewrite java.util.Timer for JDK 1.1 or 1.2.) > > Sorry for this revolutionary idea at the last minute, We'll have to talk about this. I'm a bit busy today, but maybe you can outline it a bit more for exploration? I'm thinking that it will be easier to "kill" timer tasks than individual watchdog threads. Would this work for SocketWatchdog as well as the URLWatchdogs? -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
