logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Log4J time order problem [RePost]
Date Fri, 02 Sep 2005 16:13:33 GMT

On Sep 2, 2005, at 2:13 AM, oops wrote:

> Hello.
> I also have the below problem.
> I don't use ASYNC file appender
> I just use DailyRollingFIleAppender.

The issue affects almost all appenders, it is just more easily  
observed with AsyncAppenders when the buffer gets filled.  If there  
is any lock acquisition after the LoggingEvent is constructed (and  
the timestamp is acquired), there is a chance that multiple threads  
will block and the order that the threads will restart is  
indeterminate resulting in LoggingEvents processed in a different  

There is not any reliable means of correcting the sequence once  
multiple threads block.  It would require something like holding all  
events till application shutdown and then sorting on timestamp and  
that would require large amounts of memory and be susceptible to  
application crashes.

If this is a concern to you, the best approach is to avoid situations  
that cause thread blocking.  During the time period around the out-of- 
sequence timestamps, it is likely multiple threads are awaiting for  
an IO action to complete.  With a RFA, this would be most pronounced  
during a rollover, though that does not appear to be the case here.

Using an AsyncAppender can be beneficial as long as the bufferSize is  
set sufficiently large to avoid having the buffer filled.  As long as  
the buffer is not filled, the AsyncAppender will have a much shorter  
lock than the underlying IO bound appender and the chance of multiple  
threads blocking is greatly reduced. 

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message