Re: [logback-user] RE: [logback-user] logback initialization "à la" Spring

Ceki Gulcu ceki at
Thu Sep 27 20:31:37 CEST 2007


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 

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 at>
> To: logback users list <logback-user at>
> 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 at>
> To: logback users list <logback-user at>
> 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 at
>     [mailto:logback-user-bounces at]*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 at>
>     To: logback users list <logback-user at>
>     Sent: Thursday, September 27, 2007 10:23:07 AM
>     Subject: Re: [logback-user] logback initialization "à la" Spring
>     On 9/27/07, *Davide Baroncelli* <baroncelli at
>     <mailto:baroncelli at>> 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
>     <*>
>     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 
> <*> 
> and lay it on us.
> ------------------------------------------------------------------------
> Looking for a deal? Find great prices on flights and hotels 
> <*;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20-> 
> with Yahoo! FareChase.
> ------------------------------------------------------------------------
> _______________________________________________
> Logback-user mailing list
> Logback-user at

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

More information about the Logback-user mailing list