The sequence number that was implemented in log4j 1.3 was problematic
on several fronts. In the implementation in the last release, the
same sequence number could be repeated since it wasn't guarded with a
synchronization block. I believe that it was fixed in the SVN, but
didn't make it into a release. Been a couple of years since we went
round and round on it, but search the log4j-dev archives and Bugzilla
for earlier discussions.
There are a slew of things in log4j 1.2 that "don't cut it" for
multi-core hence the desire to develop a log4j 2.0 that uses finer
locking and only targets Java 5 and later. If you were targeting
Java 5 and later, the most obvious approach would be use
System.nanoTime, however log4j 1.2.x targets earlier JVMs.
Understand the point re: Java 5. Sequence number in Java 1.5 would be
trivial...just use an AtomicLong, etc.
System.nanoTime probably needs to be done anyway, but its not a final
solution. A time stamp PLUS sequence number is required.
One of the issues that needs to be considered is that the order of the
logging calls and their order of processing by appenders can be
substantially different since there are intervening synchronization
blocks and being first to wait does not mean that you will be first to
wake up.
Set the LoggingEvent sequence number at the same time the timestamp is
set...I believe during construction of the LoggingEvent.
Using a RewriteAppender would suffer from this since it would only add
its sequence number after the thread may have been blocked for a
substantial time period. If you were to take this approach, you'd
probably do just as well just numbering the entries through a custom
layout or appender.
There have been repeated "bugs"
(http://issues.apache.org/bugzilla/show_bug.cgi?id=40303 for example)
filed when the timestamp (same would happen even more so to sequence
number) are not monotonically increasing in a log file. This is due
to the potential for reordering between the creation of LoggingEvent
and the eventual processing by the Appenders.
Understood. IMO it seems more correct that the timestamp be set as
close to the client code log.XXX(...) as possible.
Any reordering can be done later by the viewing application.
For the big picture:
log4j 2.0 intends to target Java 5 and later and follow modern
concurrency best practices, but currently it is only a concept and
some very early experimental code. While I'd love to flesh out the
framework and energize a team to built it, keeping log4j 1.2 running
and getting log4cxx is taking all my open source cycles at the moment
and nobody seems anxious to work on it.
Looks like we'll be modifying 1.2 then. Adding the sequence number,
compiling under 1.6, etc.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
