logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Logger in ASP.NET stops after a few hours, won't restart until app is cycled
Date Fri, 13 Jan 2012 18:17:45 GMT
Have you tried setting the Evaluator property:


http://logging.apache.org/log4net/release/sdk/log4net.Appender.BufferingAppenderSkeleton.Evaluator.html

to flush buffered messages when a WARN or greater message is received?

Sounds like you have a good plan for extending the built-in appender for your project. Shouldn't
be too difficult to add a timer that triggers a flush every X seconds. Be careful that your
buffer doesn't grow too large if the database is down for an extended period of time. What
you might want to do is extend BufferingForwardingAppender in such a way that it supports
the concept of a fail-over appenders. I think nlog ships with a target that is able to switch
destinations if the first one goes offline. I believe it tries to log to the original appender
on each write to the fail-over appender because it wants to get back to the primary destination
as soon as possible. I'm not certain about the implementation.



________________________________
 From: Jim Scott <jscott@infoconex.com>
To: log4net-user@logging.apache.org 
Sent: Wednesday, January 11, 2012 7:58 PM
Subject: Re: Logger in ASP.NET stops after a few hours, won't restart until app is cycled
 

 
FYI, here is the enhancements that I suggested back in Jan, 2011 that I was 
referring to in my last email.
 
I have been using the AdoNetAppender for a while now and 
have a few issues with it.
1)If the database that it logs to goes offline it will 
stop logging messages until the application is restarted 
·You can overcome that issue by setting  ReconnectOnError but the problem with that is that
if the database is still  offline it will block your program thread until it times out every
time it  tries to flush the events.
2)Since the 
AdoNetAppender derives from BufferAppenderSkeleton it buffers events before 
writing to the DB. Not a bad idea unless you want to monitor the DB for 
exceptions in real-time. So let’s say I set the default buffer size to 20 
events. If I am monitoring the DB I won’t see any of the exceptions till it hits 
the buffer size of 20 events.
·The fix for me is to set the buffer to 1 event so that  I get real-time results when an
exception happens. However I am not taking  advantage of buffering the events so that the
application thread returns  quicker and writes to the DB less frequent.
Here is the behavior I want.
1)Set by default buffer size to 100
2)Set a buffer flush interval to 60 
seconds
3)Set retry logic for DB connection in the event that the 
DB is unavailable and cache the log events being written
 
So here is an example of how it would 
work.
 
Write an exception to AdoNetAppender
Event is buffered
If buffer exceeds 100 events or 60 seconds has elapsed 
the buffer will be flushed
If the appender is unable to talk to the DB it marks the 
connection as failed and caches the events locally
Next write attempts looks to see if the retry time has 
been exceeded and if so attempts to write buffer to DB
Also 
any local events previously cached from a failure will be written as 
well.
 
So now I am back to using a buffer
I now see any exceptions at most 60 seconds after they 
happen
If the DB goes down I now have retry logic for 
attempting to write the events (key is not every attempt so the application is 
not being blocked on every write)
 
Now not being entirely familiar with the source for 
Log4Net I attempted to add these features and have it working. However not sure 
if my approach is the approach you would take for including in your source. 
 
If anyone likes the features listed above I would be 
happy to provide the source changes. I did this by creating a AdoNetAppenderEx 
class that looks just like the AdoNetAppender but with my additions. 
 
However I personally think the concept of flushing 
events on an interval should be coded up higher in the BufferAppenderSkeleton as 
the issue I don’t like is having to wait till the number of buffered events is 
exceeded. Would be nice to specify another threshold for buffered events to be 
time based.
 
The retry logic however for the DB is essential but 
don’t want it happening on every write but rather a retry after X seconds has 
elapsed since the last failed connection.
Mime
View raw message