On Thu, Oct 13, 2011 at 5:23 PM, Bart van der Schans
<b.vandersch...@onehippo.com> wrote:
> On Thu, Oct 13, 2011 at 4:51 PM, Stefan Guggisberg
> <stefan.guggisb...@gmail.com> wrote:
>> hi bart,
>>
>> On Thu, Oct 13, 2011 at 4:44 PM, Bart van der Schans
>> <b.vandersch...@onehippo.com> wrote:
>>> Hi Stefan,
>>>
>>> On Thu, Oct 13, 2011 at 4:27 PM, Stefan Guggisberg
>>> <stefan.guggisb...@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?
ok, i get your point.
> Can we use TRACE log level for the resizing
> logging?
i guess yes, that's a good idea.
cheers
stefan
> 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.
>
> Regards,
> Bart
>
>>
>> cheers
>> stefan
>>
>>>
>>> Regards,
>>> Bart
>
