commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <>
Subject RE: [pool][dbcp] instrumentation
Date Mon, 19 Nov 2007 17:14:01 GMT
sebb wrote:

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


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

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

I also see that as a concern, including for maintanence, unless the
instrumentation could be automated during the build process.

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

Given that it isn't a performance hit, and given the benefits that are
claimed, I would sooner we maintain a single branch with instrumentation
than two branches.

Phil, your thoughts?

	--- Noel

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message