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

Arthur Blake blakesys at yahoo.com
Thu Sep 27 21:57:02 CEST 2007


Ceki said:

>Perhaps the cleanest solution is to trigger reloading of the config file 
>manually via some convenient (graphical?) user interface.

I wrote a really nice ajax based graphical UI for log4j recently for a client that does all that.  
It worked out so well, I've been toying of the idea of making an open source one for logback.
I prefer logback for my own open source projects.  If there is significant interest in this I might consider doing this and either contributing to logback or open sourcing it on my own...

PS. Ceki, I have yet another open source library that is now dependent on SLF4J (see http://jabsorb.org) - nice if you could add that to the main SLF4J page.

Cheers


----- Original Message ----
From: Ceki Gulcu <ceki at qos.ch>
To: logback users list <logback-user at qos.ch>
Sent: Thursday, September 27, 2007 2:31:37 PM
Subject: Re: [logback-user]  RE: [logback-user] logback initialization "à  la"  Spring

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 at yahoo.com>
> To: logback users list <logback-user at 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 at cybershift.com>
> To: logback users list <logback-user at 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 at qos.ch
>     [mailto:logback-user-bounces at 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 at gmail.com>
>     To: logback users list <logback-user at 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 at yahoo.com
>     <mailto:baroncelli at 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 at 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
_______________________________________________
Logback-user mailing list
Logback-user at qos.ch
http://qos.ch/mailman/listinfo/logback-user







       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://qos.ch/pipermail/logback-user/attachments/20070927/62447d6a/attachment.htm 


More information about the Logback-user mailing list