On Dec 21, 2005, at 11:36 PM, Elias Ross wrote:
On Wed, 2005-12-21 at 21:09 -0600, Curt Arnold wrote:
- Locking/threading/synchronization issues
I think it will be difficult or impossible to safely address the
"locks when trying to log during a toString() call" without
potentially breaking somebody else. It is an undesirable
established
limitation of log4j, but it has existed there for a long time.
The problem in 1.3 is in the AppenderSkeleton class. Have you
examined
the proposed Appender implementations in bug 24159, which would allow
users to avoid deadlocks in 1.3 by reconfiguring their class?
I'd prefer to expedite the 2.0 branch and get log4j using a much
finer grained locking than maintaining two parallel sets of appenders
with different locking characteristics.
Much of
the log4j internals aren't thread safe by themselves and depend on
the outer
synchronization to keep things safe.
Many of the "internals" are public classes which are not really
internal at all
and need proper documentation and/or locking.
I didn't mean "internals" to mean that they should be off-limits for
review. I'll be the first to say that way too much of log4j is
visible, way too many non-final methods, non-final classes, mutable
fields, protected fields, etc. They do not need proper documentation
and locking, they need to be rewritten to avoid unnecessary locking.
However, that means changes that aren't compatible with a 1.x branch.
It is irresponsible to not state or establish the contract or
convention of how
a library's public classes can (or cannot) used within multiple
threads. Even
though, for example, a "Layout" implementation may not be typically
used outside
of a locking context or appender, it is not guaranteed or even
implied this is
how it will be used.
Most of the active developers came to the party long after the
initial design decisions. Those decisions seemed to be generally
good ones for their time, but reflect the concerns of the JDK 1.1
era. Then it is a question of our priorities, do we spend a lot of
time trying to document the potential problem scenarios in 1.x, spend
a lot of very complex and error-prone work to tweak the 1.x code to
avoid particular scenarios without breaking existing code or do we
rework the 2.0 branch to eliminate those problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
