[jbossts-issues] [JBoss JIRA] Commented: (JBTM-331) Reduce the log level of the periodic recovery stuff
Jonathan Halliday (JIRA)
jira-events at lists.jboss.org
Tue Jun 17 10:56:33 EDT 2008
[ http://jira.jboss.com/jira/browse/JBTM-331?page=comments#action_12417589 ]
Jonathan Halliday commented on JBTM-331:
Changed the log level for these statements in the arjuna code from INFO to DEBUG. Arjuna logging does not use a trace level.
At first glance it seems this change won't make any difference, since JakartaRelevelingLogger is rewriting arjuna INFO to AS DEBUG anyhow, i.e. the messages are still at DEBUG level by the time they hit the AS logging code.
However, they should now only get that far if com.arjuna.common.util.logging.DebugLevel is set, which it is not by default. (Setting DEBUG for com.arjuna in the app server log4j is not by itself enough to have arjuna DEBUG level log statements appear - debugging needs to be on in the jbossjta-properties.xml file too)
So now you'll get these messages appearing in the app server log file only if you explicitly turn on DEBUG level logging for the transaction service, not just the app server. Thus the app server is normally silent when 'idle' with a DEBUG level setting in log4j.
The alternative approach would be to modify JakartaRelevelingLogger to globally rewrite arjuna DEBUG to app server TRACE, but that's a more radical change and may have unintended side effects, so it's preferable to avoid if possible.
> Reduce the log level of the periodic recovery stuff
> Key: JBTM-331
> URL: http://jira.jboss.com/jira/browse/JBTM-331
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Recovery
> Reporter: David Lloyd
> Assigned To: Jonathan Halliday
> The JBossAS log (as of 5.0.0.Beta4) is filled with this kind of thing:
> 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <Thu, 28 Feb 2008 17:57:51>
> 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass
> 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
> 2008-02-28 17:57:51,703 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass
> 2008-02-28 17:59:51,703 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Thu, 28 Feb 2008 17:59:51>
> 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass
> 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass
> 2008-02-28 17:59:51,704 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass
> These messages ought to be at TRACE level. The first hint is that this is the only thing spamming the log after successful startup. Also on more than one occasion, folks pop into the public #jboss IRC channel asking about why their logs get spammed with these messages. An otherwise idle JBossAS instance quietly gobbles 750kb of disk space a day with these messages.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues