Thanks again Curt for your quick response. 1) The AsyncAppender buffer is a queue (FIFO), with lots of appending at its beginning, and one Dispatcher that gets the events from the other side. That's the reason I thought that LinkedList would be best. Since I'm working with many threads, I set the buffer size to 200,000 and then I reduced it to 20,000. I set it to such a big number because I didn't want to lose too much events (I'm now in block=false). However, I guess that if the implementation is ArrayList and my buffer is so big, then the performance will be poor. If I set the buffer size too small, I will lose many events (that will only be counted and summerized, instead of being logged). Do you have any recommendation for the maximum buffer size ?
2) I read that when using AsyncAppender, it is better to set the LocationInfo to "false" because otherwise, I'll miss the whole purpose of improving performance. Well.... I did that, but then I got the NullPointerException... I have no choice but to remove the %C and %L from the pattern, right ? Thanks ! -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 6:30 PM To: Log4J Users List Subject: Re: Multiple threads that log events to the same file concurrently On Oct 24, 2006, at 3:59 AM, Cohen Oren (ICS) wrote: > Thanks ! > > 1) Is there a reason why the buffer of the AsyncAppender is > implemented as ArrayList and not LinkedList ? I don't believe there has been any performance testing related to the choice of List implementation in this instance. Section 8.4.4 of "Java Platform Performance" says: > > Most of the time you need a List, the ArrayList implementation is the > best choice. ArrayList offers constant-time positional access and is > quite fast, It doesn't have to allocate a node object for each > element in the List and it uses the native method System.arraycopy to > move multiple elements simultaneously. ... > ... > > You might want to consider using LinkedList if you frequently add > elements to the beginning of the List or iterate over the list and > delete elements from the interior. ... However, keep in mind that > this performance gain might be more than offset by other factors. ... > The fixed overhead for LinkedList operations is also much greater than > for ArrayList operations. AsyncAppender does not do any of the things that might suggest using LinkedList while it does do things (like bulk copies) that ArrayList is better at. > > 2) I tried to ran on log4j 1.2.14 with the following configuration, > and got a NullPointerException (see below). > If my LocationInfo was set to "false", why did the Dispatcher get into > getLocationInformation() method ? The pattern layout attached to the rolling file appender contains %C and %L specifiers (for the class name and line number, respectively), so when the event is finally handled by the appender, it tries to collect location information from the current call stack (which will no longer contain the location of the call since the event has been delegated to another thread). There appears to be a bug in location capturing code when the call stack does not include the expected logger class. I'm guessing the same problem would also occur with earlier versions of log4j. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
