There are many cases in which the current RFA code is broken. Some of the issues are design and some are code. It can be made better, though probably not perfect. Any expected anomaly should be clearly documented. The interactions between various settings need to be better documented. In other words, set the users expectations.
I have read the history of MultiFileAppender. It sounds rather ambitious and, while a good idea, a drop in replacement for RFA is also a good idea. A new RFA would allow upgrade to new log4Net release to gain stability without forcing a configuration change to a new appender. I found the bug report (40066) on gaps to be of particular interest. It appears to be saying exactly what I seen on many occasions. ---------------------------------------------------------------------- Roy Chastain -----Original Message----- From: Curt Arnold [mailto:curt.ar...@gmail.com] On Behalf Of Curt Arnold Sent: Monday, September 12, 2011 00:40 To: Log4NET Dev Subject: Re: The state of RollingFileAppender The rolling file appenders are the single greatest cause of recurring problems in log4j and all those problems have been inherited by log4net. I don't think that the rolling file appenders are fixable. Any approach that involves systematic renaming for files is not going to be robust. Even a single rename operation can be expensive and the rollover time is linear with the number of log files maintained which can result in non-responsive apps as the log file history grows. log4j (and possibly log4net) are stuck with retaining the known-to-be problematic rolling file appenders for compatibility, but use of these appenders should be discouraged. There was a sandbox development of a MultiFileAppender (a file appender which could manage multiple open files) for log4j several years ago and it seemed like the use cases for the rolling file appenders could be addressed within the MultiFIleAppender. One of the weaknesses of the existing RFA's were that they closed the previous log file before opening the new log file which could land the appender in limbo if it could not open a new log file and could not reopen the old log file. This link should catch most of the earlier discussion, but it has been a long time since I've reviewed those messages: http://search.gmane.org/?query=MultiFileAppender&author=&group=gmane.com p.jakarta.log4j.devel&sort=revdate&DEFAULTOP=and&xP=multifileappender&xF ILTERS=Gcomp.jakarta.log4j.devel---A--A The sandbox code can be checked out from http://svn.apache.org/repos/asf/logging/sandbox/log4j/multifile
