On Jan 31, 2005, at 3:11 PM, Ceki G�lc� wrote:
At 09:51 PM 1/31/2005, Curt Arnold wrote:
Recently, I stumbled upon an interesting use case for sequenceCount. When the AsynAppender buffer is full and a event is processed, one of the waiting threads is notified that a slot became available. The order in which threads are notified is not specified by the Java language. They can be notified more or less in random order.
Consequently, events may be output out of order by AsynAppender. Sequence count can help the user to order the output.
The above should be viewed as a marginally important use case for sequenceCount, but a use case it is nonetheless.
I think the scenario described would affect any appender that needs to synchronize a shared resource (like the event queue, socket, file etc) which would include almost all appenders. In the case of an asych appender, there would be an opportunity to reorder events into request time instead of dispatch time while in the queue, however you would not have that opportunity with say a SocketAppender. So I think that users will just have to accept that messages in the log from a multithreaded application may appear in a slightly different sequence than the requests were made.
Then the question becomes what to do if the millisecond timestamp is not sufficiently precise for the analytical need. Use of a high-performance timer (like System.nanoTime) might be a better solution than getSequenceCount. However, if you really need to know the precise timeline of a multithreaded app, it might be something that you might have to handle in the calling application. Even without a synchronization issue, it would be possible for two nearly simultaneous calls to logger.debug to have the LoggingEvent constructor (where the timestamp is determined) in a different order since the cost of walking the tree may vary and the thread priorities may be different.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
