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 <[EMAIL PROTECTED]>
To: logback users list <[email protected]>
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 <[EMAIL PROTECTED]>
To: logback users list <[email protected]>
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:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
To: logback users list <[email protected]>
Sent: Thursday, September 27, 2007 10:23:07 AM
Subject: Re: [logback-user] logback initialization "à la" Spring
On 9/27/07, *Davide Baroncelli* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
[email protected]
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
[email protected]
http://qos.ch/mailman/listinfo/logback-user
