XA-related failures in JMS bridge reconnection tests

[jmesnil]

I've ported the JMS Bridge tests to our integration tests (using 2 invm servers instead of spawned ones).

Most tests pass but there are failures related to XA (QoS once-and-only-once + separate servers for the source and target queues).

I've not touched that much the bridge code or the bridge tests so it's likely a regression we have on the trunk wrt XA.

I'm still investigating the issue but a commented instruction caught my attention in BridgeImpl.setupJMSObjects():

 if (forwardMode == FORWARD_MODE_XA && sourceSession instanceof JBossSession)
 {
 JBossSession jsession = (JBossSession)sourceSession;

 ClientSession clientSession = jsession.getCoreSession();

 //clientSession.setTreatAsNonTransactedWhenNotEnlisted(false);
 }

this setTreatAsNonTransactedWhenNotEnlisted flag is no longer present in JBM trunk but I wonder if it rings any bell for people who worked on JBM 1.4 (it seems mostly related to JBMESSAGING-946)?

[clebert.suconic]

The setTreatAsNonTransactedWhenNotEnlisted was a hack to couple with TCK and the way that JCA would interact with JMS.

We had to add that hack as we couldn't change the JCA code.


But the use of the attribute on the Bridge seems non related to this. You probably need to make sure you aways have XA on the test. (Maybe the test is not valid for JBM2?)

[timfox]

The same issue is discussed here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151340&start=10