JBAS-5278 Errors .

[vickyk]

I have been seeing the following error in org.jboss.test.jca.test.ExecuteJMSDuringRollbackStressTestCase testcase .

2008-04-01 17:58:53,658 TRACE [org.jboss.resource.connectionmanager.TxConnectionManager] (WorkerThread#0[127.0.0.1:59944]) commit problem:
org.jboss.resource.JBossResourceException: Could not commit LocalTransaction; - nested throwable: (javax.jms.TransactionInProgressException: Cannot call commit on an XA session)
 at org.jboss.resource.adapter.jms.JmsLocalTransaction.commit(JmsLocalTransaction.java:60)
 at org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource.commit(TxConnectionManager.java:990)
 at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:110)
 at com.arjuna.ats.arjuna.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:170)
 at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:441)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2639)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1784)
 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1390)
 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
 at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
 at org.jboss.test.jca.test.ExecuteJMSDuringRollbackStressTestCase.setupQueue(ExecuteJMSDuringRollbackStressTestCase.java:262)
 at org.jboss.test.jca.test.ExecuteJMSDuringRollbackStressTestCase.testExecuteJMSDuringRollback(ExecuteJMSDuringRollbackStressTestCase.java:72)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

These details I have found from the server log .

I am not sure why this is failing here .
What could be the problem ?

I made changes in the test-jms-local-ds.xml at tx-connection-factory

<xa-transaction/>

This got me the rid of the above exception but the test failed with this error details

Expected one text message: null
java.lang.RuntimeException: Expected one text message: null
 at org.jboss.test.jca.test.ExecuteJMSDuringRollbackStressTestCase.checkQueue(ExecuteJMSDuringRollbackStressTestCase.java:280)
 at org.jboss.test.jca.test.ExecuteJMSDuringRollbackStressTestCase.testExecuteJMSDuringRollback(ExecuteJMSDuringRollbackStressTestCase.java:99)

Any inputs here ?

[clebert.suconic]

The real question is.. why the test disables <xa-transaction/>?

We could certainly uncomment the <xa-transaction> and investigate why the failure is happening. Adding the xa-transaction might remove the failure condition but might hide a bug depending on the intention of the test.

[clebert.suconic]

This is a JCA adapter bug.

I - org.jboss.resource.adapter.jms.JmsManagedConnection doesn't know if JmsXA supports XA or not
II - JBossMessaging Connection Factories will implement both XAConnectionFactory and ConnectionFactory
(BTW: There is nothing wrong with this. This is just an implementation point).

III - JmsManagedConnection will use an instanceof to determine if it should open an XA or a regular transaction:

You will find lots of things like:

 if (con instanceof XATopicConnection)
 {
 xaTopicSession = ((XATopicConnection)con).createXATopicSession();
 topicSession = xaTopicSession.getTopicSession();
 xaTransacted = true;
 }
 else if (con instanceof TopicConnection)
 {
 topicSession =
 ((TopicConnection)con).createTopicSession(transacted, ack);
 if (trace)
 log.trace("Using a non-XA TopicConnection. " +
 "It will not be able to participate in a Global UOW");
 }

Instead of relaying on the implementation details of the ConnectionFactory, IMO JCA should be extending JmsConnectionRequestInfo to determine if the request is for a XA or a non XA connection.

I believe this would be an issue with other JMS implementations as well (besides JBossMQ).

[clebert.suconic]

A kludge on this would be to create a delegate ConnectionFactory on the JCA Layer that will only implement the required interface, which is like putting a wire replacing the fuse when it breaks. It works now, but it can be worse later.

That is a terrible solution, I don't like it.. but I just wanted to give that as an idea (Brain storm). I guess it would be possible to implement the delegate transparently without changing any configuration files (what would have implications on documentation as well).

[jesper.pedersen]

I'm going to provide a new implementation that will fix the problem targeted towards AS-5.0.CR1.

I don't think that documentation is an issue here, since it needs to be updated for AS-5.0 anyway.

Keeping the configuration in the same format seems to be a good idea -- if possible.

[timfox]

Pasting in some relevant comments by Jesper:

"jesper" wrote:

By popular request I took a look at subject - here follows my analysis.

First of all: Clebert's comment on this issue is correct - it _IS_ a JCA issue !

The following two classes

org.jboss.resource.adapter.jms.JmsManagedConnection
org.jboss.jms.ConnectionFactoryHelper

assumes that _just_ because the JMS ConnectionFactory bound in JNDI implements the XA interfaces that the functionality is enabled and always used. This is _not_ correct - the JMS spec doesn't say anything about that.

JBossMessaging lets its classes implement both the non-XA and XA interfaces all over the implementation - e.g. JBossConnectionFactory implements ConnectionFactory and XAConnectionFactory.
Messaging should be a black box from a JCA point of view - it can't assume anything about non-XA and XA use from a user point of view - it needs to keep track of it for each session. JBossMessaging implements precisely this at the session layer.


Problem 1) - this needs to be fixed if JBossMessaging is to be a 1st-class citizen of EAP-4.3, AS-5.0 and at a later point EAP-5.0 (!).
Problem 2) - using JMS in the AS-5.0 (and EAP-4.3) doesn't work correctly now AFAICT. We need to commit/rollback the transactions where they belong.


As to 1) - we can extend the current implementation such that it will become a more 'XA capable JCA adaptor' which can be used with AS-4.2, AS-5.0, EAP-4.3 and EAP-5.0 -- this will require some resources. I need to go over all of the 7k LoC implementation and move/remove all assumptions on how the messaging implementation works - and run the TCK of course. Furthermore I properly need to extend the transaction tracking inside the adaptor.

(I don't see this as a long-term solution - e.g. new implementation in AS-5.1 and EAP-5.1 is needed IMHO).

[timfox]

Here is another thread on this subject from about a year ago:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040064

[timfox]

[The relevant parts start on the third page]

[timfox]

JIRA link: http://jira.jboss.com/jira/browse/JBPAPP-750

[timfox]

"jesper.pedersen" wrote:
I'm going to provide a new implementation that will fix the problem targeted towards AS-5.0.CR1.

I don't think that documentation is an issue here, since it needs to be updated for AS-5.0 anyway.

Keeping the configuration in the same format seems to be a good idea -- if possible.

Great news!

While you're rewriting can you get rid of the usage of ConnectionConsumer too? It's horrible and not all JMS implementations provide a connection consumer.

[jesper.pedersen]

Will do, Tim !

My goal is to provide an implementation that doesn't depend on optional features - such as the ConnectionConsumer interface.

[adrian.brock]

"jesper.pedersen" wrote:
Will do, Tim !

My goal is to provide an implementation that doesn't depend on optional features - such as the ConnectionConsumer interface.

Why are you even spending time on this? It certainly doesn't need a re-write since it
should be obsolete. The jms rar is only there for jms implementations that don't
provide their own rars (e.g. the old jbossmq).

The real solution is for JBoss Messaging to provide its own resource adapter.
It can then use internal api to optimize the behaviour rather then the under
documented ConnectionConsumer/ServerSessionPool.

[jesper.pedersen]

Hi Adrian.

Currently JBossMessaging doesn't have its own ResourceAdaptor as you know.

JBossMessaging is being deploy in EAP as the default messaging provider together with the current JCA/JMS adaptor. This results in errors in the testsuite like JBPAPP-750.

For AS-5.0 and EAP-4.3 I'll help the messaging team by providing the ResourceAdaptor as you describe - and later we should provide an optimized version using the internal API.

Also we should use all your ideas from the jboss-jca project and in JIRA for a new implementation of the JCA specs for the next version of the AS.

But if requirements for the EAP platform is only to use JBossMessaging for its messaging implementation we can go directly to the internal API implementation.

[jesper.pedersen]

Quick follow up: having a ResourceAdaptor implementation that works with JBossMessaging would allow us/users to deploy JBossMessaging in other scenarios.

So there a plus on that side.

[timfox]

For JBM 2.0 I don't want to have to write a connection consumer implementation at all (since it's a horrible thing), in which case, as Adrian points out a JBM resource adaptor will need to use some kind of JBM internal API and won't work with other JMS systems.

So question is does this become part of JBM or remain in the JCA project? I'm not too bothered either way. One thing to bear in mind is I suspect the JBM specific RA can re-use a fair bit of code from the generic one, so we need to think where that shared code lives.

Jesper - if you want to lend a hand that's great. We could spin this off as a JBM sub project.