Part B tests recover and continue using the journal from the previous run. Only dtx tests fail in this manner. Examination of the journal instances leading up to the failure shows that txtest uses a sequence of xids starting at 1 and incrementing. However, part B tests are fairly short-lived, and only add a few records to the journal. That means that during recovery (which start by looking at the oldest files and progressing to the newer ones) may stumble upon dtx transactions from older tests which happen to use the same xid as that of in-doubt transactions in the last test being recovered. This can cause the incorrect records to be enqueued/dequeued as part of the recovered transaction and may result in either a shortfall or excess of records at the end of the test. This is a problem in txtest itself; the fix is to change the xids to be random rather than sequential.
txtest was fixed in r.720910. txtest now uses the 36-char string representation of UUIDs for xids. QA: Repeat testing for part B and check for failures.
Validated that issue has been fixed (7 runs), validated on RHEL 4.7 / 5.2, i386 / x86_64 on packages:qpidd-0.3.722122-2.el5, rhm-0.3.2898-1.el5. ->VERIFIED
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0035.html