commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [pool][dbcp] instrumentation
Date Mon, 19 Nov 2007 20:48:42 GMT
On 11/19/07, Noel J. Bergman <noel@devtech.com> wrote:
> sebb wrote:
>
> > 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?
>
>  ref: http://www.crazysquirrel.com/computing/java/logging.jspx
>      http://tomcat.apache.org/tomcat-6.0-doc/logging.html
>      http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-su
> mmary.html
>
>
> > > 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?

Thanks for the feedback.  I agree that maintaining a single branch is
best, but what I am struggling with is how ugly the already complex
code becomes when I add (appropriately flagged) trace-level logging
capabilities, which I have found useful in troubleshooting issues.

I guess the best approach is to forego trace-level logging and get
some basic instrumentation into trunk.  I will start committing this
for pool and dbcp and welcome suggestions for improvement.

Any other comments on the naming, levels, use of JUL before I start?

Phil

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