Red Hat Bugzilla – Full Text Bug Listing
|Summary:||consider reducing the amount of time tx recovery waits before expiring txs|
|Product:||[Other] RHQ Project||Reporter:||John Mazzitelli <mazz>|
|Component:||Core Server||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED DEFERRED||QA Contact:|
|Target Milestone:||---||Keywords:||FutureFeature, Improvement|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-08-24 14:27:19 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description John Mazzitelli 2008-11-29 15:00:00 EST
The following in jbossjta-properties.xml define settings that expire transactions that may need recovery. Consider reducing the amount of time lower than the current 12 hours. Its possible this is the cause of our log files getting flooded with recovery error messages - if a transaction can't be recovered after X hours, it will be expired, but before X hours, it will be retried every 2 minutes (that 2 minute time frame is also configured in here). <!-- Interval, in hours, between running the expiry scanners. This can be quite long. The absolute value determines the interval - if the value is negative, the scan will NOT be run until after one interval has elapsed. If positive the first scan will be immediately after startup. Zero will prevent any scanning. Default = 12 = run immediately, then every 12 hours. --> <property name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/> <!-- Age, in hours, for removal of transaction status manager item. This should be longer than any ts-using process will remain running. Zero = Never removed. Default is 12. --> <property name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
Comment 1 John Mazzitelli 2008-12-09 23:23:24 EST
Unfortunately, that setting will not work in the current JBossAS used in RHQ: https://jira.jboss.org/jira/browse/JBTM-418 We'll have to either upgrade to the latest JBossAS or patch JBossAS with the JBossTM fix for that jira.
Comment 2 Red Hat Bugzilla 2009-11-10 15:27:51 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1196
Comment 3 wes hayutin 2010-02-16 12:10:09 EST
mass add of key word FutureFeature to help track
Comment 4 Corey Welton 2010-08-18 11:22:27 EDT
mazz, is this still an issue?
Comment 5 John Mazzitelli 2010-08-24 14:27:19 EDT
we don't need this setting anymore, we've not had problems with our tx logs anymore. close this out as DEFERRED since we really don't need it. If in the futuer we do need it, we'll have to revisit this.