Bug 1289386

Summary: [GSS](6.4.z) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detect
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: dstephan
Component: Transaction ManagerAssignee: Ivo Studensky <istudens>
Status: CLOSED CURRENTRELEASE QA Contact: Ondrej Chaloupka <ochaloup>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.4.5CC: bbaranow, bmaxwell, clichybi, dstephan, istudens, jtruhlar, ochaloup, tom.jenkinson
Target Milestone: CR1   
Target Release: EAP 6.4.8   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 12:34:58 UTC Type: Bug
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: 1279553, 1289990    

Description dstephan 2015-12-08 00:39:15 UTC 
Description of problem:

There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g.
a->b b->c

When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b".

This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks.
Comment 1 JBoss JIRA Server 2015-12-15 09:59:14 UTC 
Tom Jenkinson <tom.jenkinson> updated the status of jira JBTM-2575 to Closed
Comment 6 Ondrej Chaloupka 2016-05-12 04:20:24 UTC 
Verified with 6.4.8.CP.CR2 and Narayana in version 4.17.32.Final

The behavior was checked with reproducer at
https://github.com/ochaloup/ejb-call-one-other/
Comment 7 Petr Penicka 2017-01-17 12:34:58 UTC 
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.
Comment 8 Petr Penicka 2017-01-17 12:56:47 UTC 
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.