At 02:10 AM 12/29/2004, Curt Arnold wrote:
Didn't doubt the amount of mental activity. However, I didn't want to guess at the motivation behind it and could find no discussion in the archives.
Although everyone is encouraged to hold technical discussions on this list, sometimes they occur elsewhere. You are correct to observe that such discussions do not leave a public trace which is one of their major inconveniences.
From our recent discussion, the motivation wasn't to provide a sequencing that could be used to detect dropped messages in transmission. Something like that had been requested requested on the log4cxx lists in the recent past though I didn't follow through to see what their requirements were.
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.
So there are at least 3 major reason causing receiving end of an appender to observe gaps in the sequence number of events it receives, even in the case of "lossless" and orderly delivery by the transmission channel.
Is it a requirement that these identifiers be monotonically increasing?
I was going to write "DBReceiver makes use of the monotonic increase of the sequenceNumber to make successive queries." However, I just checked and making this statement would have been incorrect because DBAppender uses a separate sequence number, totally independent of the sequence number found in logging events.
To answer you question, the monotonic increase of sequence numbers in LoggingEvent is *not* a requirement.
For example, could getSequenceNumber and setSequenceNumber be renamed to getEventID and setEventID (where they change in name would lose the semantics that the number should be higher for later events) and still fulfill the objective?
The current name is a direct consequence of the way the numbers are generated. I am not aware of any algorithm which is simpler than "sequenceNumber = sequenceCount++" or one that would do a better job. In the absence of a better algorithm, the current name is satisfactory because it corresponds to how the number is generated. However, if anyone has a better algorithm to suggest, in particular one avoiding or reducing synchronization, then I'd be highly interested.
BTW, the name "eventId" would also be quite satisfactory.
-- 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]
