logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Proposed synchronization changes
Date Fri, 06 Jun 2008 00:19:57 GMT
For my own usage I went ahead and completed the a set of changes to 
reduce log4j 1.2.x's locking and deadlock potential.  The results are 
attached and make unabashed use of Java 5 -- as from discussion to this 
point it seems clear that there is no interest in making any of these 
sorts of changes in log4j 1.2.x yet I felt the need for such 
improvements now and only care about Java 5 and later environments.

For anyone interested this patch set makes the following changes:

    * Removed the synchronization bottleneck in Category.callAppenders()
      and AppenderAttachableImpl.
    * Added AppenderAttachableImpl5, a Java 5 specific alternative to
      AppenderAttachableImpl, and used CopyOnWriteArrayList to further
      reduce locking during append.  Used this from Category rather than
      AppenderAttachableImpl but left AppenderAttachableImpl around for
      any for compatibility with any subclasses as
      AppenderAttachableImpl5 does not use a protected Vector field as
      subclasses would expect.
    * Added PreFormattingLayout interface, which provides methods to
      precompute the formatted string, e.g. prior to entering a
      synchronization block in existing Appender code, and then use the
      precomputed string from within this block.
    * Amended AppenderSkeleton to automatically make use of these
      methods for any layout implementing PreFormattingLayout.
    * Modified PatternLayout to implement PreFormattingLayout.
    * Updated DatePatternConverter to be thread-safe yet non-blocking.
    * Amended AbsoluteTimeDateFormat's constructors to initialize the
      numberFormat field which DateFormat internally assumes is non-null
      (e.g. in equals and clone) but does not initialize.
    * Addressed thread-safety/race issue in WriterAppender.
    * There are probably some other thread-safety/race fixes in there I
      forgot about -- I kept noticing these things as I was examining
      the code.

Collectively these changes allow:

    * Appender implementations involving no locking whatsoever upon
      append (or no additional locking beyond the minimum required).
          o I created an AppenderSkeleton alternative for our own usage
            similar to ConcurrentAppender but different in several respects.
                + ConcurrentAppender relies on all sorts of stuff from
                  outside the core log4j jar -- I didn't want to.
                + ConcurrentAppender introduces a notion of 'closed'
                  state and a read-write lock -- I wanted to leave that
                  to subclasses which need it and not burden others with
                  this.
                + ConcurrentAppender uses a guard to prevent
                  re-entrancy.  I examined some of my custom appenders
                  and found this totally unnecessary in some cases --
                  and thus didn't want this in the base class.
                + Etc...
    * Use of existing Appenders without the locking encompassing
      PatternLayout formatting.
          o This increases multi-threaded throughput and reduces
            deadlock potential (which logging from within
            message.toString() can all too easily cause today).
          o This could be done with other layouts as well, but we are
            currently primarily using PatternLayout.
          o Again, I chose not to use the PatternLayout from the
            concurrent sandbox as it introduces dependencies outside the
            core log4j.jar.

As for log4j 2.0, there are a number of important questions to be answered:

    * How much of the non-core should be relied upon -- especially for
      core capabilities?  [I'd the default core appender base class
      should be concurrent.]  How much should move into the core and
      replace existing stuff there?
    * Do we really care about anything prior to Java 5 with log4j 2.0? 
      I'd argue not.  log4j 1.2.x works well enough for pre-Java-5 and
      Java 5 provides compelling advantages.
    * Etc...

--
Jess Holle


Mime
View raw message