Regarding item #2 about AdoNetAppender and it extending from 
BufferAppenderSkeleton, I believe you can use

<lossy value="true" />
<evaluator type="log4net.Core.LevelEvaluator">
 <threshold value="WARN"/>
</evaluator>

To trigger an immediate flush of the buffer if a WARN or higher message is 
encountered.




________________________________
From: Jim Scott <[email protected]>
To: [email protected]
Sent: Thu, January 6, 2011 3:43:07 PM
Subject: AdoNetAppender feature changes needed

 
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.
 
Thoughts?
 
Thanks
Jim  Scott

Reply via email to