On Jun 30, 2006, at 4:10 PM, Elias Ross wrote:
This thread is to discuss adding a "concurrent" library to the Log4j
"trunk".
I wrote this library primarily to avoid deadlock situations as
explained
in bug 24159. In addition to avoiding deadlock situations, I believe
the bug 33855 explains the reason for wanting to provide a
"concurrent"
appender package, in addition to the existing logging appenders.
An adequate analogy might be having java.util.Hashtable and
java.util.concurrent.ConcurrentHashMap in the same library.
Now, in addition to simply merging the code over, I have also some
patches against the main Log4j that I recommend applying as well.
http://issues.apache.org/bugzilla/attachment.cgi?id=17613 (start from
the bottom)
Quite a few of the changes in that attachment or alternative takes on
the same issues have already been applied to trunk. I've review the
changes to the layout classes and have committed changes (rev 418432)
that I believe addressed your concerns with the Layout classes. If I
missed something let me know and attach issue specific patches.
The main "fix" is to make the various Layout classes thread-safe.
Now,
I can actually adapt my code to assume non-thread-safety, but it seems
reasonable to require that all layouts used with the concurrent
appenders be thread safe and that all Log4J supplied layouts should be
thread-safe.
Additionally you'll see in the, I did notice that buffered I/O by
default does help performance quite a bit, and even combined with
flushing per message helps out. I do suggest changing the default
to be
the faster configuration.
I'd be very reluctant to change the default value of a significant
configuration parameter. However, if we were to consider it, I'd
suggest filing a distinct bug and calling for a separate vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
