RollingFileAppender does not work for 10 threads. 1. It does not roll over 2. It truncated the file when it should roll over, but never appends it again. 3. It happened very often
I make the file size to 2MB or 4MB. Is it a limitation for the file size?
The RollingFileAppender is designed to work in a multi-threaded setting. Would it be possible for you to supply a test case? Many thanks in advance.
In the abscense of further information, I am marking this bug report as WORKSFORME.
I also have this problem but are unable to generate a test scenario. It occurs only under heavy load after a few hours of running. Could problem be related to the code in subAppend method? It seems to be related to the null-pointer exceptions issues in the subAppend method. If one thread rolls over, the fileName might temporarily be reset to null. A second thread will write using a null filename. I added a test in subAppend before calling the super method. It resolves my case but it is not a full solution because there is still some theoretical problem. protected void subAppend(LoggingEvent event) { if(fileName != null) super.subAppend(event); if((fileName != null) && ((CountingQuietWriter) qw).getCount() >= maxFileSize) this.rollOver(); }
From an initial reading of the bug report this might be that two threads contend for rolling over the files (i.e. the triggering happens in two threads so the operations get mixed). Perhaps a synchronized block around the renaming-bit could help? Suggestions?
May be the reason : The SocketServer TCP/IP server is designed to manage 10 (or 11 ?) maximum threads . See org.apache.log4j.net.SocketServer.java constructor : public SocketServer(File directory) { this.dir = directory; hierarchyMap = new Hashtable(11); } There must be some mixing or hidden bugs between the clients if exceeding 10 clients. Thanks for your feedback if this is the right reason. See http://d.cr.free.fr/wswebconsulterfichiers.php?projet=demojava_log4j for (many..) extra bugs in log4j
(In reply to comment #6) > May be the reason : > The SocketServer TCP/IP server is designed to manage 10 (or 11 ?) maximum > threads . > See org.apache.log4j.net.SocketServer.java constructor : > public > SocketServer(File directory) { > this.dir = directory; > hierarchyMap = new Hashtable(11); > } > There must be some mixing or hidden bugs between the clients if exceeding 10 > clients. > Thanks for your feedback if this is the right reason. > See http://d.cr.free.fr/wswebconsulterfichiers.php?projet=demojava_log4j for > (many..) extra bugs in log4j 11 is the initial allocation size for hierarchMap, of course, which is the default anyway. May be a lack of memory + unmanaged allocation error ?
(In reply to comment #7) > > SocketServer(File directory) { > > this.dir = directory; > > hierarchyMap = new Hashtable(11); > > } > > There must be some mixing or hidden bugs between the clients if exceeding 10 > > clients. > > Thanks for your feedback if this is the right reason. > > See http://d.cr.free.fr/wswebconsulterfichiers.php?projet=demojava_log4j for > > (many..) extra bugs in log4j > > 11 is the initial allocation size for hierarchMap, of course, which is the > default anyway. May be a lack of memory + unmanaged allocation error ? It is unusual to provide the initialCapacity to the HashTable constructor (especially for such a low value) but not illegal. http://java.sun.com/javase/6/docs/api/java/util/Hashtable.html#Hashtable(int) Could you please elaborate on why your tool thinks these two cases are related?