Loading...

log4net-user@logging.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

RE: Logger in ASP.NET stops after a few hours, won't restart until app is cycled stephanie.giovannini Wed Feb 01 14:06:03 2012

Thanks for your input!

That is, of course, the problem. The site is up all day. One of the sources of 
messages logs something every time a user logs in. Thus, any minor database 
downtime or timeout could cause a connection failure.

I’ll be setting the ReconnectOnError to true immediately, but I agree with your 
idea. I haven’t messed with log4net code, but I’ve written services that handle 
database downtime just as you’ve suggested. In those cases, the source input 
was not dependent on the database (data was coming in from factory equipment), 
there was no user interaction, and it was acceptable to buffer the input until 
the database came back up.

I’m not sure my current application needs the same functionality because the 
site is completely dependent on the database. If the database is down, then 
every query is timing out for every user and nothing can be done. The logging 
hardly matters. Of course, I can’t log database-down errors, but that’s not my 
primary interest in logging.


From: Jim Scott [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 11, 2012 6:58 PM
To: [EMAIL PROTECTED]
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.