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 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?
I never went deep into the concurrent contribution. The project
accepted it in the sandbox from Elias Ross and granted him commit
rights for continued development, but it did not develop a community
and Elias drifted away.
Having anything in an appender or layout that in turn calls log4j is
unsafe and may likely cause infinite recursion. log4j 1.2.x won't
stop you from that. Looks like the concurrent contribution attempted
to block it.
I think incrementally improving log4j 1.2, particularly in the area of
concurrency is a morass. Since individual components of log4j 1.2
were not designed to be thread-safe and the contract with extensions
allowed them to not be thread-safe, removing any existing
synchronization block is extremely difficult to be proved generally
safe. Removing the category synchronization lock may work for you or
allow the unit tests to run (which are far from a thorough test of
log4j), but it screams like the type of thing you don't do in the 16th
dot release.
The log4j 2.0 approach was to design the fundamental building blocks
designed for concurrency and JDK 1.5 and then when that foundation was
sufficiently established, start migrating appenders and writing log4j
1.2 emulation on top of it. Right now it is a few experiments in the
sandbox and not as accessible as I would like. If I were going to
spend my time on concurrency related issues, the best use of my time
would be to make it more accessible and complete. If you are
interested in contributing to that, I'd be willing to change my
priorities and update that.
If you really want to work on an incremental approach, I'd be willing
to create and apply your patches to a branch of log4j 1.2 in the
sandbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
