Hi Jim. What you're saying makes a lot of sense to me. I wasted two days troubleshooting what turned out to be a permissions issue last week because I wasn't aware that log4net would disable the appender upon connection error. I was trying to log in a web app's startup, which runs under the pool's identity (I know that NOW) and in the global error handler which was executing under the user's impersonated identity (which did have permission). Because the pool had no permission to the database, I got nothing, even for the user, and this was really hard to figure out. You're suggesting a solution that might work well in real world scenarios where everything isn't perfect. A connections to a DB could drop momentarily and that probably shouldn't mean game over. I might want to see an entry indicating previous failures, though. That would help troubleshooting, especially if it's able to flush previous entries. I'm surprised there's any application blocking. I assume log4net was returning immediately and processing requests on a background thread.
________________________________ From: Jim Scott <jsc...@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.
