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