On Sat, 2005-01-29 at 01:34, Curt Arnold wrote:
> Sorry, A committer who blindly checked in code they hadn't reviewed
> would likely not remain a committer for long. Actually, they would
> more likely get very hostile emails. If anyone in the community is
> just dying to use your patches, there is nothing to stop them from
> merging it into their working builds. However, by committing it into
> the CVS, I'm at least forcing the changes on the 40 projects or so in
> Gump that build against our nightlies.
How would my patch break the build or their build?
Assuming I don't change any existing code, only add new classes and
methods, this wouldn't force any changes on this other projects.
> Currently all our performance tests are single threaded. In this case,
> we need a mock multithreaded application that will dispatch log
> messages to identify contentions. There are a variety of tools that
> can be used to collect and analyze the system under test, but you need
> to frame the benchmark problem first.
I included a mock application to perform some simple benchmarking with
my patch, did you not see it? This is how I measured the large amount
of contention in the current 1.3 code base. It also showed about a 10%
increase in performance on multi-processor machines.
> Sorry, "getSequenceCount" was a short-hand reference to a fairly
> involved thread about a month ago. A sequence number is currently
> being used as a logging event identifier, but there are likely better
> ways of meeting the actual requirements. The thread is pretty long and
> convoluted, most of it was trying to figure out what the actual
> requirements were. Having a monotonically increasing message sequence
> number wasn't one of them. Having an implementation of equals and
> hasCode were requirements (from the Chainsaw team).
I don't see why the Chainsaw team is causing grief for you. If their
particular application requires "equals" and "hashCode", they can
implement their own wrappers as appropriate for logging events.
It appears their requirements are negatively impacting the base
architecture of log4j. I'm sure there is a reasonable compromise to be
made.
> Sounds like the "Doctor. it hurts me when I do this" joke. There are
> certain operations (like retrieving location information) that are
> known to be expensive. log4j provides mechanisms to get the info if
> you really want it. The cost is high, but avoidable.
Did you look at the code? ThrowableInformation.extractStringRep is
called when you do
Logger.debug("", new Throwable());
Is there any particular reason why for JDK 1.4 reflection is used to
print the stack trace?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
