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] Usage of logging API in common-pool ?
Date Sun, 20 Jul 2014 14:54:42 GMT
On 7/19/14, 5:45 PM, Gary Gregory wrote:
> I just had a case today actually, where I had to unroll PoolUtils.prefill
> and add logging before each call to addObject().

Why?

Nine times out of ten, when you think you need logging when using
[pool], you can get what you need by instrumenting *your* factory. 
In pool2, you also have all of the lifecycle stuff in the
PooledObjects and the JMX instrumentation.

>  Quite a shame to be forced
> to do that because pool does not log. In the end, this helped me debug my
> problem but now, I'm leave the code unrolled of course. IMO, pool is a
> mid-level component that should log; and do so with Log4j 2.

If [pool] is midlevel, what exactly is low-level?  Pool is depended
on by lots of projects for a pretty simple, low-level function and
it has no dependencies itself.  Performance and lightweight
deployment are important.  In 2.0, we have added good JMX
instrumentation and I think with the right listeners, we should be
able to handle everything but the few internal corner cases like
OOMEs that write to System.err in the current code.  Adding a
logging dependency just for these seems a shame to me.   If we
decide we have to add something, it should be commons-logging, for
consistency with [dbcp] and for the same reasons that choice was
made [1].  I would really like to avoid it, if possible, though. 

[1] http://markmail.org/images/permalink.gif

Phil
>
> Gary
>
>
> On Sat, Jul 19, 2014 at 6:35 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>> On 7/18/14, 2:18 PM, Anthony Communier wrote:
>>> Hello,
>>>
>>> There are some parts of the code that use printStackTrace in order to
>> show
>>> errors. It means that it's difficult to have control on how log will be
>>> produced. Those stacks will mainly go to application server logs and not
>>> directly into application logs if an application server is used (like
>>> tomcat, Jboss, ..). That's why I suggest to use logging API, like other
>>> libraries
>>>
>>> I have posted an issue in Jira POOL-266 (
>>> https://issues.apache.org/jira/browse/POOL-266). Phil Steitz added a
>>> comment on the issue (Today 21:1)
>>>
>>> "The reason that we don't use a logging API is to avoid introducing a
>>> dependency. If we do go that route, we should be consistent with DBCP and
>>> use commons-logging. I am not sure we really want to go this way,
>> though. I
>>> am more inclined to support the suggestion in POOL-267. It would be
>> better
>>> to discuss these things on the commons dev mailing list."
>> Unfortunately, the POOL-267 approach works only for the abandoned
>> instance tracking part.  I had forgotten that we have in fact added
>> some printStackTraces for errors (sort of extreme cases, but
>> still...) in 2.x.  We need a solution for these as well.  See [1]
>> for previous discussion of this topic.
>>
>> Now that we cut 2.x releases, we obviously have to think about
>> compatibility.  I think the listeners stuff should be able to be
>> done compatibly; but adding a dependency is probably not something
>> we want to do in a dot release.
>>
>> What would be great would be a way to add listeners / configuration
>> options that would make it possible for users to pipe trace info to
>> whatever persistence mechanisms they want.  We have talked about
>> this in the past, but never settled on an approach.  Again, see
>> [1].  I tend to agree with the sentiment that a low-level component
>> like [pool] should emit very little, ideally nothing, in terms of
>> logging, but provide good access to the information needed by
>> components up the stack to handle and report errors and gather
>> diagnostic information.
>>
>> Phil
>>
>> [1] http://markmail.org/message/zuufedzkfx62v5eq
>>>
>>> Regards,
>>>
>>> Anthony Communier
>>>
>>
>> ---------------------------------------------------------------------
>> 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