
Hello, Because it dispenses with the need of a separate watchdog thread, I believe that the approach discussed here has significant merit. It could be placed into a custom TurboFilter. TurboFilters get called very early in the processing of a log statement. In other words, they get called every time, regardless of the level of the logger in question. The if(now > nextCheckStamp) check should avoid superfluous access to the configuration file. Of course, the value of "now" would need to be computed anew for each log statement. Preliminary tests show that a call to System.currentTimeMillis() costs about 70 nanoseconds. Admittedly, 70 nanoseconds is not much but when compared to the cost of a disabled log statement (10 nanoseconds), it becomes an non-negligible issue. In short, the approach is promising, with a small but non-negligible computational cost. Perhaps the cleanest solution is to trigger reloading of the config file manually via some convenient (graphical?) user interface. Arthur Blake wrote:
Probably one objection to this scheme would be an extra overhead on each and every log message-- if you really look into it though, this overhead is really really minor- I think if implemented correctly, it would amount to just an extra long comparison on each log message. e.g.
if (now > nextCheckTstamp) { // kick off async file check // and then update nextCheckTstamp }
Where "now" is a variable that you presumably would already have around anyway...
----- Original Message ---- From: Arthur Blake <blakesys@yahoo.com> To: logback users list <logback-user@qos.ch> Sent: Thursday, September 27, 2007 1:11:04 PM Subject: Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring
Not necessarily, the reload check could be done before the OFF check...
----- Original Message ---- From: Tom Leccese <tleccese@cybershift.com> To: logback users list <logback-user@qos.ch> Sent: Thursday, September 27, 2007 12:57:36 PM Subject: [logback-user] RE: [logback-user] logback initialization "à la" Spring
One snafu, perhaps. If all your loggers in your current config are turned OFF, then a message would never get generated, and it would never check to see if the config file has changed.
-----Original Message----- *From:* logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch]*On Behalf Of *Arthur Blake *Sent:* Thursday, September 27, 2007 12:45 PM *To:* logback users list *Subject:* Re: [logback-user] logback initialization "à la" Spring
I've used automatic reloading in the past in log4j and it certainly can be a very nice and convenient feature--
There are various issues that come up in the complexity of implementing it -- normally it's done with a separate Thread that runs and wakes up every so often to check if the file timestamp on the config file has changed.
Thats a bit of a clunky and complex way to do it.
I have been mentally toying with an idea for a new way to accomplish this, without having to have a separate thread-- The check could be done at the point where each log message is generated-- system wide.
Since you already know the timestamp of the message generated, you could just compare that to the timestamp of the last time the log config file was reloaded-- and if a certain amount of time has elapsed since the last time the file was checked, you kick off the code that checks to see if the file time stamp has changed, and if so, reload it (that part could be done asynchronously as well so as not to slow down other threads writing out log messages)
It's simple, fast and it would have the very nice benefit of not having to have a separate Thread-- furthermore, you avoid the overhead of periodically checking the modification file stamp, over long periods when there is no log activity (such as idle periods when a server might not be getting any activity)
Has anyone thought of implementing it this way?
----- Original Message ---- From: Jorg Heymans <jorg.heymans@gmail.com> To: logback users list <logback-user@qos.ch> Sent: Thursday, September 27, 2007 10:23:07 AM Subject: Re: [logback-user] logback initialization "à la" Spring
On 9/27/07, *Davide Baroncelli* <baroncelli@yahoo.com <mailto:baroncelli@yahoo.com>> wrote:
P.s.: let me express my disagreement for logback and sl4j not supporting neither the FATAL logging level nor automatic reloading of config files.
+1 for automatic reloading !
Jorg
------------------------------------------------------------------------ Catch up on fall's hot new shows <http://us.rd.yahoo.com/tv/mail/tagline/falltv/evt=47093/*http://tv.yahoo.com/collections/3658%20> on Yahoo! TV. Watch previews, get listings, and more!
This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal.
------------------------------------------------------------------------ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel <http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7%20> and lay it on us.
------------------------------------------------------------------------ Looking for a deal? Find great prices on flights and hotels <http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-> with Yahoo! FareChase.
------------------------------------------------------------------------
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch