Jacob Kjome wrote:
Hi Jess,
I suggest you post a tracking bug report for this so that these changes don't
just
get lost on the list.
I may manage to get to this prior to leaving on vacation. My changes
won't be lost for me at any rate :-)
Sounds like you did a lot of great work that could be
Curt Arnold wrote:
On Jun 5, 2008, at 7:19 PM, Jess Holle wrote:
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 clea
Hi Jess,
I suggest you post a tracking bug report for this so that these changes don't
just
get lost on the list. Sounds like you did a lot of great work that could be the
basis for Log4j-2.0. Maybe you can gather up enough steam to make 2.0 a
reality.
And I agree. JDK1.5+ should be what 2.0
On Jun 5, 2008, at 7:19 PM, Jess Holle wrote:
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
Jess Holle wrote:
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 -
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 change
On May 20, 2008, at 4:19 AM, Jess Holle wrote:
Curt Arnold wrote:
On May 19, 2008, at 11:22 AM, Jess Holle wrote:
If it is sufficiently compelling it appears it would be possible
to rework AppenderSkeleton without breaking most extensions
thereof but allowing Layout.format() to be hoisted
Curt Arnold wrote:
On May 19, 2008, at 11:22 AM, Jess Holle wrote:
If it is sufficiently compelling it appears it would be possible to
rework AppenderSkeleton without breaking most extensions thereof but
allowing Layout.format() to be hoisted out of the synchronization
block in cases where the
On May 19, 2008, at 11:22 AM, Jess Holle wrote:
If it is sufficiently compelling it appears it would be possible to
rework AppenderSkeleton without breaking most extensions thereof but
allowing Layout.format() to be hoisted out of the synchronization
block in cases where the Layout is an in
Jess Holle wrote:
Curt Arnold wrote:
Exactly. Almost nothing inside of log4j 1.2.x is inherently
thread-safe and depends on a big, coarse-grained synchronization lock
to insure safety. Almost any incremental improvement has the
potential for breaking compatibility.
Significantly improving
Curt Arnold wrote:
Exactly. Almost nothing inside of log4j 1.2.x is inherently
thread-safe and depends on a big, coarse-grained synchronization lock
to insure safety. Almost any incremental improvement has the
potential for breaking compatibility.
Significantly improving the concurrency re
On May 19, 2008, at 10:22 AM, Jess Holle wrote:
Jess Holle wrote:
Thanks.
I'm also starting to ponder whether there's a mostly compatible way
to reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would
allow the String to be
Jess Holle wrote:
Thanks.
I'm also starting to ponder whether there's a mostly compatible way to
reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would allow
the String to be pre-computed prior to holding the lock (but after
f
Thanks.
I'm also starting to ponder whether there's a mostly compatible way to
reduce locking in AppenderSkeleton and WriterAppender.
For instance, we could add a special Layout interface that would allow
the String to be pre-computed prior to holding the lock (but after
filters and threshol
I sorry that I haven't had time to look at your proposal but hope to
on Monday.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 desire
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
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
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
19 matches
Mail list logo
