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 Tue, 20 Nov 2007 07:56:42 GMT
On Nov 19, 2007 11:46 PM, Jörg Schaible
<Joerg.Schaible@elsag-solutions.com> wrote:
>
> Phil Steitz wrote:
> > 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?
>
> Why not using commons-logging? It supports trace level. JUL is really a pain. It is applicable
for applications like Tomcat, but not really for components. Everybody that tried to use an
own JUL-formatter knows what I mean. Big enterprise companies normally hesitate or simply
do not permit to add 3rd party jars to the JVM classpath.

Can you explain more what you mean about third party jars here?  It
was general pushback / hesitancy to bring in dependency on
commons-logging (or anything else) that led us to think about just
using jdk logging.  I was going to add a simple formatter (all that I
need is to expose the thread ID) and bundle it with pool, making it
also available to dbcp.

I am open to either approach and don't particularly care which API we
use.  I just want to minimize conflict / configuration hassles for
users.

Phil

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


Mime
View raw message