commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [pool][dbcp] instrumentation
Date Tue, 20 Nov 2007 06:46:59 GMT
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.

- Jörg

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


Mime
View raw message