My problem is very similar to the problem described on this page: http://issues.apache.org/bugzilla/show_bug.cgi?id=41735 So to describe in more detail: In my application a logfile is written into, there is an appender describing that as follows: <appender name="PLM1" class="org.apache.log4j.RollingFileAppender"> <param name="Append" value="true"/> <param name="File" value="plmconsole.txt"/> <param name="MaxBackupIndex" value="5"/> <param name="MaxFileSize" value="10MB"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%-5p %-10X{UserName} %m%n"/> </layout> </appender> But this logfile plmconsole.txt does not honour the 10 MB MaxFileSize and also I am not able to see the rolled over files plmconsole.txt.1 ... etc. One more piece of information is that in my application there are several classes and they are all writing into plmconsole.txt . This is important in the light of the fact that I have one more logfile and appender combination whose appender is described exactly as above, but to which just one class is writing, and this file gets rolled over satisfactorily. I went to this page and found that "this one is marked as complete in log4j 1.2.15" , so tried to run the application against log4j 1.2.15 , but this does not help. Regards
> This is important in > the light of the fact that I have one more logfile and appender combination > whose appender is described exactly as above, but to which just one class is > writing, and this file gets rolled over satisfactorily. Does this logfile have a different name, or is it also named plmconsole.txt? What operating system and JVM are in use? Are you running under an application server, if so what version? Could you attach your entire configuration file? Does the configuration file work or fail with a trivial application? If so, could you attach your test app to the bug? Did you try to set the system property log4j.debug to true? Did the console output provide any diagnostics? Do you have any indexing servers that might be preventing the file from being renamed? Did you try running tools that report open files to see if multiple processes might have the file open?
I have also had this issue in my own use of log4j. Basically, if a RollingFileAppender is used from multiple VMs pointing at the same file, the RollingFileAppender will not properly roll. I believe this is due to log4j caching the state of the log files. This cache is ineffective as there are forces at work writing to the file outside of the specific instance of the RollingFileAppender. I wonder if the submitter found a way to reproduce this issue while having defined multiple rolling file appenders in the same log4j config file all pointing at the same file. I would imagine this might cause a similar issue with the caching of file sizes.
as of 1.2.16, the method rollOver() in RollingFileAppender does not produce any diagnostic output if one or more of the file rename(s) fail, even with log4j.debug=true. Should produce a warning about failed renames.