Re: Sequence count, WAS: Why concurrency?

[Elias Ross <er...@m-qube.com>]

On Mon, 2005-01-31 at 14:53, Curt Arnold wrote:

> 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.

Which is sort of the reasoning behind having the appender generate the
sequence number -- not the class itself.  Then, you be sure that events
appearing in a file would appear in the correct order.  This would be
part of the contract for Appender.doAppend.

For appenders that don't have any reason to generate the sequence number
(WriterAppender, et all.) you don't generate one.  ChainsawAppender and
SocketAppender would create one.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: Sequence count, WAS: Why concurrency?

[Elias Ross <er...@m-qube.com>]

On Mon, 2005-01-31 at 16:27, Curt Arnold wrote:

> and these messages were dispatched to two distinct appenders (possibly 
> of different types) and that one instance of Chainsaw was listening to 
> both, it could determine that which logging events came from the same 
> iteration of the loop.

An assign sequence number method could first check if a sequence number
was already assigned:

class LoggingEvent ... {
  public synchronized void assignNewSequenceNumber(long count) {
    if (this.sequenceNumber != 0)
      return;
    this.sequenceNumber = count;
  }
}

class ChainsawAppender {
  long seq = 0;
  public synchronized void doAppend(LoggingEvent le) {
    le.assignSequenceNumber(seq++);
  }
}

Or:

class LoggingEvent ... {
  static long count;
  private synchronized void writeObject() {
    if (this.sequenceNumber == 0) {
      synchronized (LoggingEvent.class) {
        this.sequenceNumber = count++;
      }
    }
  }
}



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: Sequence count, WAS: Why concurrency?

[Curt Arnold <ca...@apache.org>]

On Jan 31, 2005, at 5:19 PM, Elias Ross wrote:

> On Mon, 2005-01-31 at 14:53, Curt Arnold wrote:
>
>> 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.
>
> Which is sort of the reasoning behind having the appender generate the
> sequence number -- not the class itself.  Then, you be sure that events
> appearing in a file would appear in the correct order.  This would be
> part of the contract for Appender.doAppend.
>
> For appenders that don't have any reason to generate the sequence 
> number
> (WriterAppender, et all.) you don't generate one.  ChainsawAppender and
> SocketAppender would create one.
>

If you go back to the earlier thread on sequence number when I was 
trying to find out the motivation behind it, I speculated that it might 
have been added to allow detection of dropped messages.  If that had 
been the case, then an appender based sequence number might have been a 
reasonable approach.  However that was not the motivation.  The 
motivation was to have some sort of object ID so you could tell the 
difference between two serialized forms of logging events that were 
identical in all aspects (message, timestamp, etc) except arose from 
distinct requests.  For example, if I had a very tight loop like 
(assuming each iteration) takes less than 1 ms:

for (int i = 0; i < 10; i++) {
     logger.debug("Hello, world");
}

and these messages were dispatched to two distinct appenders (possibly 
of different types) and that one instance of Chainsaw was listening to 
both, it could determine that which logging events came from the same 
iteration of the loop.

Even if the sequenceCount was done on the appender level, it still does 
not solve the sequence indeterminacy issue since there would need to be 
a synchronization block on its sequenceCount which could still result 
in the first request to block on the lock possibly not being the first 
to acquire the lock when it becomes available.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org