commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: [pool][dbcp] instrumentation
Date Tue, 20 Nov 2007 06:46:59 GMT
Phil Steitz wrote:
> On 11/19/07, Noel J. Bergman <> wrote:
>> 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?
>>  ref:
>> 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.

- Jörg

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

View raw message