[JBoss JIRA] Created: (JBMESSAGING-661) Resolve Xid incompatibility
by Juha Lindfors (JIRA)
Resolve Xid incompatibility
---------------------------
Key: JBMESSAGING-661
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-661
Project: JBoss Messaging
Issue Type: Sub-task
Components: Messaging Core
Reporter: Juha Lindfors
Assigned To: Juha Lindfors
Priority: Blocker
Fix For: 1.0.2.CR1
There is an issue between JBossTS Xid and JBMessaging Xid implementations not resolving to equal with same globalID, branch qualifier and format id settings.
It seems to be related to the fact that JBossTS Xids get padded to a fixed byte length which causes a mismatch in the equals() method implementation.
E.g.
Xid xid1 = new XidImple(new Uid("gbtxid1"), new Uid("bq1"), 123); //JBossTS(GID, branch, format)
Xid xid2 = new XidImpl("bq1".getBytes(), 123, "gbtxid1".getBytes());
assertEquals(xid1, xid2);
returns false.
This is an issue since currently the JBMessaging does not enforce a single Xid implementation to be used but assumes Xid as a valid key based on its global tx id and branch qualifier contents. Furthermore this assumption of key equality is likely to fail due to comparison of format IDs which are expected by definition to differ across implementations.
The issue manifests itself during recovery where at server startup recovered prepared transactions are reinstantiated and populated into tx map using JBMessaging Xid implementations. Once the coordinator requests these transactions to be committed, it will pass as an argument its own Xid instances which will fail on lookup.
Discussing various options with Adrian, the best solution appears to be to modify the XAResource interface implementation to enforce single Xid implementation inside messaging by replacing all incoming Xid references with a known implementation. This will avoid the inconsistency within tx map when Xids are used as identifying keys.
--
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
17 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-627) Create an ant configuration file fragment that would build a Messaging configuration for the AS testing, adding things like securiy roles, etc.
by Ovidiu Feodorov (JIRA)
Create an ant configuration file fragment that would build a Messaging configuration for the AS testing, adding things like securiy roles, etc.
-----------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-627
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-627
Project: JBoss Messaging
Issue Type: Sub-task
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Fix For: 1.2.0.Beta1
Richard Achmatowicz:
In order not to interfere with your use of the existing Messaging configuration with your tests (functional, stress, etc), it seems as though we need to add a target to release-admin.xml which builds a Messaging configuration for the AS testing. Does this sound reasonable?
Ovidiu Feodorov [26/Oct/06 10:06 PM]:
I would rather keep it separated. I see it more of a function of the testsuite build script. The release admin does need not care of security roles in JBoss AS integration test suite. I can create the ant configuration script fragment for you to use, if you wish, it shouldn't be any big deal. The changes should be applied post-deployment.
Richard Achmatowicz [27/Oct/06 11:22 AM] Yes, please, I would appreciate it if you could create the fragment. Because that fragment will contain rexexp terms, which are messy and should not be present in-line in testsuite/build.xml, i'll create a separate ant script containing your snippet and place it in resources/jbossmessaging.
--
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
17 years, 9 months