On Thu, 2005-07-14 at 17:25 -0500, Curt Arnold wrote:
>
> I agree that it is too potentially disruptive to attempt in 1.2.x.
> I'm not ready to commit to doing it in 1.3, however. log4j currently
> does fairly coarse synchronization which has been raised as an issue
> repeatedly (the whole concurrent appender proposal, for example) and
> refactoring synchronization would likely be a 2.0.x type of change.
I'm the person who filed the bug 1 1/2 years ago...
Despite having to wait, I agree that 1.2 is probably too early and
likely too disruptive. You would have to change the synchronization
behavior of AppenderSkeleton, which would subtly break classes that
extend AppenderSkeleton or its subclasses.
In 1.3, you have already cleaned up the coarse locking in the Category
(Logger) class with respect to adding and removing appenders by using a
read-write lock. This is a step in the right direction. My concurrent
appender uses the same read-write class and my AppenderSkeleton (called
ConcurrentAppender) is nearly identical in implementation to the
original, except for a few additional finer-locked objects.
For 1.3, it would be reasonable to include a concurrent appender tree.
In addition to having better performance and less coarse locking (and no
dead-locks), it would be a reasonable parent class for network- and
JDBC-based loggers. Eventually, they could form the basis of appenders
in a future release.
>From working with application services (namely JBoss) for over two
years, it is imperative to have a logging subsystem that is dead-lock
free and high-performance on two and four-processor machines. Although,
we do not log a huge volume typically, it is necessary for debugging a
live a system. My original complaint came from debugging a third-party
library on a application system.
I would at least appreciate people code review my work. The subclasses
of WriterAppender (for example, my ConsoleAppender.java and
FileAppender.java) are identical except for the package name. If you
are planning on breaking compatibility ("cleaning up") many existing
classes for 1.3, please consider moving to a concurrent model. If not,
please include it as a sub-tree.
Many thanks,
Elias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
