commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject [pool][dbcp] instrumentation
Date Mon, 19 Nov 2007 03:13:36 GMT
I have been working on adding logging to pool and dbcp per previous
discussion here.  I started with a partially instrumented version of
pool 1.3 that I have been using to investigate bug reports and test
performance.  I used jdk logging with the following guidelines

* Finest (trace) level for detailed/diagnostic logging
* Finer level for things a commons developer may want to know
* Fine (debug) level for things a developer of an app using this
component may want to know
* Config level for configuration-modification events
* Info level for things a system administrator may want to know
* Warning level for things indicating a recoverable problem
* Severe level for things indicating a problem that the component
could not recover from

I used fully qualified class names for loggers, flags, logp and a
custom formatter that adds the thread id to the log message.

While running with Config or higher levels, there does not appear to
be any measurable performance impact, the instrumentation seriously
clutters the already complex code.  So I guess what I would like to
propose is that we release both fully instrumented and minimally
instrumented jars for these components, with the minimally
instrumented version in trunk and a "-inst" version built from a copy
of the release tag.  This is essentially what I have done for  (most
of) pool 1.3, which I would like to complete and commit to a branch
and release as pool-1.3-inst or somesuch.  Similarly for
dbcp-1.2.2-inst and then for subsequent versions.

I know this seems like extra work for components that we are lacking
volunteers for, but it could really help in resolving user issues if
instrumented jars were available.  Alternatively, we could just move
forward with dbcp 1.3, pool 1.4, adding "Config-level" logging (or
event notification) only.  Thoughts?

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message