[jboss-dev] Re: Excessive logging in AS 4.2.3 and AS 5

Jay Balunas jbalunas at redhat.com
Tue Dec 23 13:59:33 EST 2008


The threshold you're referring to should be the exception not the  
rule.  I'll admit I have not been following all of this closely, but I  
thought the only reason we did not set logging to INFO by default was  
because CI builds need to have DEBUG set.

I'm still confused why we don't just set a default value in log4j  
config file for the log setting to INFO.  Since I can see the need to  
have a scriptable (i.e. command line) way to override for CI builds  
the we can use the ability to override via command line ( which I  
thought log4j supported anyway ).

Parting thoughts before the holidays ;-)
-Jay


On Dec 23, 2008, at 12:53 PM, Darran Lofthouse wrote:

>
> One drawback of this new Threshold is that to enable TRACE logging  
> you are forced to set the property - 
> Djboss.server.log.threshold=TRACE as even if this property is not  
> set TRACE logging will be disabled just by the presence of this  
> setting.
>
> Secondly I don't believe this is going to cause isDebugEnabled() to  
> return false as the category is still set to the default so  
> expensive operations wrapped by isDebugEnabled will still be called.
>
>
> Brian Stansberry wrote:
>> https://jira.jboss.org/jira/browse/JBAS-6205 is done.
>> Shelly, if there is going to be a new server-manager release, how  
>> about we add a -Djboss.server.log.threshold=DEBUG to the args that  
>> get passed when an AS is started?  That's a quick way to ensure  
>> testsuite configs launch with the correct level if we move the  
>> default to INFO.  Otherwise we'd have to figure out all projects  
>> that use server-manager and edit their build file server:config  
>> elements.
>> Jay Balunas wrote:
>>> OK thanks for the update.  This property should make it very easy  
>>> to adjust this for the test environment while still allowing us to  
>>> ship AS5 in a configuration that does not created MBs of logs.
>>>
>>> On Nov 17, 2008, at 3:13 PM, Brian Stansberry wrote:
>>>
>>>> Jay Balunas wrote:
>>>>> ----- "Brian Stansberry" <brian.stansberry at redhat.com> wrote:
>>>>>> I see 3 different issues here:
>>>>>>
>>>>>> 1) Code that does per-request logging at DEBUG level instead of  
>>>>>> TRACE.
>>>>>>
>>>>>> That's in violation of the logging standards and should be fixed.
>>>>> +1 and that is what we are seeing to some extent.  We don't  
>>>>> regularly need to known every time a class is loaded, or a  
>>>>> persistence connection is closed.
>>>>>> 2) How much we log at DEBUG as part of service startup/ 
>>>>>> shutdown. IMHO, this is not a huge problem.  We should probably  
>>>>>> clean it up some, but
>>>>>>
>>>>>> the point of the logging is to make problem diagnosis easier,  
>>>>>> not to produce small logs for infrequent events.
>>>>> Start up time in no little issue, but in general I agree.  if  
>>>>> there is extra logging during start up thats fine.  The real  
>>>>> issue is the reoccurring logs
>>>>>> 3) The default loggging level for server.log. If #1 is broken,  
>>>>>> then having it be INFO makes sense, otherwise we punish users  
>>>>>> for our problems.  If #1 is fixed, then different people can  
>>>>>> have different preferences, which I expect we're about to  
>>>>>> debate here. :-)  My
>>>>>> personal one is to leave it at DEBUG, unless we can make it  
>>>>>> configurable via system property substitution.  Otherwise all  
>>>>>> testsuite runs will log
>>>>>> at INFO unless we introduce testsuite hacks to replace the  
>>>>>> logging conf.
>>>>> IMO - I would like to see it at info, and use an ant command to  
>>>>> adjust the debug level for hudson builds.  Why punish our users  
>>>>> so that the continuous builds log enough.
>>>>
>>>> Log4j supports a basic system property substitution, so the  
>>>> server.log logging level can be controlled that way. I'll  
>>>> selfishly add that -- since it will help Bela in some stuff he's  
>>>> doing this week that in turn helps me. ;)
>>>>
>>>> https://jira.jboss.org/jira/browse/JBAS-6205
>>>>
>>>> Note that JBAS-6205 doesn't include changing the default to INFO.  
>>>> I think INFO's fine, but it's not my call and in any case it's a  
>>>> separate JIRA that involves some extra work (to get the  
>>>> testsuites to log at DEBUG).
>>>>
>>>>
>>>> -- 
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss, a division of Red Hat
>>>> brian.stansberry at redhat.com
>>>
>




More information about the jboss-development mailing list