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 Layout is an instance of some special
interface. [I was hacking away at this approach when I ran into the
issue with PatternLayout.] The point here would be to reduce the
bottleneck imposed by today's Appenders and Layouts while only
reworking some Layout classes.
--
Jess Holle
Did you check out the "concurrent" contribution in the sandbox,
http://svn.apache.org/repos/asf/logging/sandbox/log4j/concurrent? See
also http://marc.info/?l=log4j-dev&m=110623974420412&w=2.
I think I knew about this a long time ago, but I'd forgotten about it.
It looks like a good start on producing a parallel Appender hierarchy.
It would seem that one could use the concurrent PatternLayout from here
with existing Appenders if one adds a tag interface to the concurrent
PatternLayout and some extra code to AppenderSkeleton -- if this proved
compelling. Also, one nit: the concurrent PatternLayout.format() should
use StringBuilder, not StringBuffer.
That said, none of this would seem to buy you /anything/ if you don't
remove the synchronization bottleneck in Category.callAppenders(), e.g.
as per my patch. This patch would enable a high-concurrency branch.
Without this patch, everything is still bottlenecked in Category as best
I can tell.
As we are very far along in the log4j 1.2.x lifetime, removing
synchronization points in the main-line of the code is very high risk
activity. The concurrent proposal basically created a parallel
package of classes that had different synchronization guarantees and
so would not require proving that a particular modification would be
safe for all potential uses.
I'm fine wit the concurrent proposal except that Category still needs to
be changed. I also wonder whether an ability to opt-in to improved
concurrency by using a concurrent Layout and an existing
"non-concurrent" Appender would be helpful.
One question: I notice ConcurrentAppender uses 'guard' to explicitly
prevent re-entrancy. I don't notice anything to this effect in the
existing "main-line" Appenders. Am I missing something? Or is there an
intent in existing Appenders to allow re-entrancy? Or do they just not
guard against this and run into issues upon re-entrancy?
--
Jess Holle
