In case it's not obvious the other major issue I'm alluding to is the
synchronization in AppenderSkeleton.
This is harder to remove without breaking things -- and might be better
addressed by an AppenderSkeleton2 or by an extra argument to the
AppenderSkeleton constructor indicating the desired synchronization policy.
At least this issue can be worked around by creating your own appender.
Jess Holle wrote:
By the way, I am aware that these changes don't (yet) address the
opportunity for deadlock. That'll come later (hopefully).
This just *reduces* both the bottleneck and deadlock potential.
Jess Holle wrote:
I made a slight adjustment to the pre-Java-5 solution and replaced it
(unconditionally here, though this could easily be made conditional)
with a Java 5 implementation.
Jess Holle wrote:
We as many others have been bitten by the synchronization nuances of
log4j.
Attached is a proposed patch to reduce the scope of the problem.
No, this is not yet regression tested due to the issues I e-mailed
about previously with the regression test suite, but I'd like to
spur some discussion as to what's wrong with such a change, etc.
I was considering using Java 5 features here and could, but the key
issue here does not appear to require such fanciness to address.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]