commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool][dbcp] instrumentation
Date Mon, 19 Nov 2007 12:44:24 GMT
On 19/11/2007, Phil Steitz <phil.steitz@gmail.com> wrote:
> 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

Might have been better to use one of the logging facades - or can JUL
be configured to co-operate with other logging implementations?

> * 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.

So there are now two versions of code that need to be maintained:
- a simpler trunk
- more complicated tag version

Seems to me that this adds a huge load to the release process, unless
some way can be found to add the logging automatically. In which case,
one could develop trunk without logging, and add the logging just to
the release.

AIUI, *every* release tag will need to be converted to an instrumented release.
Or every change to trunk will need to be added to the instrumented version.

I don't think this is sustainable.

> 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?

Given that the instrumentation does not seem to impact performance, it
seems unfair to force the user to swap jars in order to provide
logging facilities.

But whatever is done, I agree that some logging is needed in the normal jars.

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

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


Mime
View raw message