Bug 535589 (RHQ-2269)

Summary:	unrecoverable transactions never clean up
Product:	[Other] RHQ Project	Reporter:	John Mazzitelli <mazz>
Component:	Core Server	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	cwelton, jshaughn
Target Milestone:	---	Keywords:	SubBug
Target Release:	---
Hardware:	All
OS:	All
URL:	http://jira.rhq-project.org/browse/RHQ-2269
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-06 20:40:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	565628

Description John Mazzitelli 2009-07-24 14:13:00 UTC

mazz: suppose I have a unrecoverable tx in the tx-object-store... every 2 minutes the tx reaper dumps messages about it - how long before the tx recovery mechanism gives up and stops trying to auto-recover?
jhalliday: depends on the config. for the current EAP it will never give up. or surrender :-)   And it's not the reaper, it's the recovery manager.
mazz: ahhh... that's what we are seeing... I thought for some reason it would stop after 24 hours or something.. I must be thinking of something else
jhalliday: that's behavior is possible, it's just not enabled by default.
mazz: can you point me to a wiki/doc that shows how to configure that
jhalliday: which version of the server?
mazz: 4.2.3.GA community distro
jhalliday: ahh, ancient history.  right, I'll do a bit of archeology and mail you the config when I get time.

"Short answer is, the code you need is not in the version of JBossTS used by AS 4.2.3.GA You'd need to backport AtomicActionExpiryScanner from a later release before you can wire it up via the properties file. see JBTM-300 and JBTM-301 --jhalliday"

Comment 1 Red Hat Bugzilla 2009-11-10 21:01:09 UTC

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2269

Comment 2 wes hayutin 2010-02-16 16:58:25 UTC

Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 3 wes hayutin 2010-02-16 17:03:17 UTC

making sure we're not missing any bugs in rhq_triage

Comment 4 Corey Welton 2010-11-22 19:40:42 UTC

 mazz - under what conditions are they unrecoverable, how do we get into this state and how often does it occur?

Comment 5 John Mazzitelli 2010-11-22 20:07:51 UTC

I don't think this can occur today - even though we are setup for XA/2PC transactioning, none of our tx's require 2PC and thus nothing should be going in the tx-object-store. And if nothing gets in the tx-object-store, we don't have to worry about things getting left there.

This issue was probably created back in the day when we mistakenly were using bad transactioning in our JMS message beans. That is no longer the case.