Hello Elias,
Currently, the sequence counter is managed per copy of the LoggingEvent class. If multiple logging repositories share the same log4j.jar file, then they will share the same sequence counter. I suppose the sequence counter could be managed per logger repository. However, managing them per logger does not make any sense. If this is not obvious, think of appender additivity.
At 06:15 PM 12/30/2004, Elias Ross wrote:
On Thu, 2004-12-30 at 03:03, Ceki Gülcü wrote:
> You couldn't possibly the sequence counter incremented within > LoggingEvent to detect dropped messages. First, sequenceCounter is a > class static variable shared by all LoggingRepositories within a JVM, > all of which increment the same counter. Second, Appenders do not > receive all logging events associated with a logging repository. (When > a logger L causes an LoggingEvent to be generated, Appender A might > not be on the path of logger L.) Moreover, an Appender can choose to > drop events due to its own filters or its threshold.
It seems fairly logical that if you distinguish logging events per logger, you should have a sequence count per logger rather than per a LoggerRepository. It would also reduce thread locking contention, assuming different parts of the program are executing on different processors.
(I'm the guy who's brought concurrency up on this list before. I think concurrency is a big deal, especially when writing code for multi-processor and hyper-threading machines which are increasingly the norm.)
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
