jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: svn commit: r1182835 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core: cache/AbstractCache.java cache/CacheManager.java persistence/bundle/AbstractBundlePersistenceManager.java
Date Thu, 13 Oct 2011 15:23:32 GMT
On Thu, Oct 13, 2011 at 4:51 PM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> hi bart,
> On Thu, Oct 13, 2011 at 4:44 PM, Bart van der Schans
> <b.vanderschans@onehippo.com> wrote:
>> Hi Stefan,
>> On Thu, Oct 13, 2011 at 4:27 PM, Stefan Guggisberg
>> <stefan.guggisberg@gmail.com> wrote:
>>>> -        if (log.isDebugEnabled()) {
>>>> +        if (log.isInfoEnabled()) {
>>> what's the justification for changing the log level from debug to info?
>> This is to make a distinction between the debug logging of the cache
>> resizing which logs quite a bit of info every second and the logging
>> of the cache (access/hit/miss) stats which log every minute
>> (configurable). It's comparable to the logging of the stats of the
>> bundle cache in 1.x which was also set on info.
> thanks for the explanation. i'd prefer to stick to the debug log level
> for this kind of polled, i.e. repeating status information. the info
> log level is
> imo fine for logging single status change events (e.g. 'repository started')

In general I agree. In this particular case, how can we log the stats
on debug without flooding the logs with the debug output from the
resizeAll() method? Can we use TRACE log level for the resizing
logging? Or is there some configuration trick in the logging (log4j)
config that I'm missing that can be used to achieve that? I guess this
"problem" will solve itself once we get the JMX bindings in place.


> cheers
> stefan
>> Regards,
>> Bart

View raw message