On Dec 9, 2007, at 11:46 AM, Paul Duffy wrote:
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.
Do you have any thoughts on the scenario where multiple JVM's are
sending LoggingEvents to a common destination. In that case, you
could get an low-resolution order from looking at the timestamps
(assuming clocks are in sync), but naively looking at sequence numbers
could be very confusing if the values overlap. Guess you could start
the sequence with a random number. Any idea of how JDK 1.4 logging
seeds its sequence number? I definitely would reserve some value to
indicate "no sequence number available".
Looks like we'll be modifying 1.2 then. Adding the sequence number,
compiling under 1.6, etc.
It would be great if you could submit your changes in a bug report so
that it could be considered for inclusion or that at worst somebody
with the same need does not need to reinvent the wheel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
