JBossDeveloper

Here is something concrete, although I'll spare you the source of the ProviderAdapter which I believe is not relevant.

A few pieces from the startup sections of my server.log.

First, a connection and session pool for GenericJMSBean is created:

:
[JMSContainerInvoker] context: javax.naming.InitialContext@6963d0
[JMSContainerInvoker] jndiSuffix: FhntStor
[JMSContainerInvoker] Got destination type Queue for GenericJMSBean
[ConnectionFactoryHelper] using connection factory: progress.message.jclient.xa.XAQueueConnectionFactory@4eb043
[ConnectionFactoryHelper] using username/password: poe/poe
[ConnectionFactoryHelper] created XAQueueConnection: progress.message.jclient.xa.XAQueueConnection@7864fe
[JMSContainerInvoker] looking up session pool factory: java:/StdJMSPool
[StdServerSessionPool] initializing with connection: progress.message.jclient.xa.XAQueueConnection@7864fe
[StdServerSessionPool] setting session listener: org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl@497904
[StdServerSession] initializing (pool, session, xaSession): org.jboss.jms.asf.StdServerSessionPool@4e28b, progress.message.jclient.QueueSession@354362, progress.message.jclient.xa.XAQueueSession@5b0e2c
[StdServerSessionPool] added server session to the pool: org.jboss.jms.asf.StdServerSession@7f9053
:

This is repeated for 15 sessions.

Next, a new connection and pool for NotisBean:

:
[JMSContainerInvoker] context: javax.naming.InitialContext@6963d0
[JMSContainerInvoker] jndiSuffix: FhntNotis
[JMSContainerInvoker] Got destination type Queue for NotisBean
[ConnectionFactoryHelper] using connection factory: progress.message.jclient.xa.XAQueueConnectionFactory@472243
[ConnectionFactoryHelper] using username/password: jms/jms
[ConnectionFactoryHelper] created XAQueueConnection: progress.message.jclient.xa.XAQueueConnection@1a8416
[JMSContainerInvoker] looking up session pool factory: java:/StdJMSPool
[StdServerSessionPool] initializing with connection: progress.message.jclient.xa.XAQueueConnection@1a8416
[StdServerSessionPool] setting session listener: org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl@35e6e3
[StdServerSession] initializing (pool, session, xaSession): org.jboss.jms.asf.StdServerSessionPool@49630a, progress.message.jclient.QueueSession@5572a, progress.message.jclient.xa.XAQueueSession@1daa0e
[StdServerSessionPool] added server session to the pool: org.jboss.jms.asf.StdServerSession@79860
:

At last, the two containers are started and an error appears.

:
[JMSContainerInvoker] Starting JMSContainerInvoker for bean GenericJMSBean
[JMSContainerInvoker] Starting JMSContainerInvoker for bean NotisBean
[StdServerSessionPool] getting a server session
[StdServerSessionPool] using server session: org.jboss.jms.asf.StdServerSession@7f9053
[Default] javax.jms.JMSException: The session and the connection consumer must be created from the same connection
[Default] at progress.message.jclient.aspi.pq.handleMessage(:252)
[Default]
[Default] at progress.message.zclient.MessageHandler.doNextWorkItem(:186)
[Default]
[Default] at progress.message.zclient.go.threadMain(:116)
[Default]
[Default] at progress.message.zclient.DebugThread.run(:56)
:

This error occurs only when using XAConnections. Non XA works fine, except the UOW warning message for every Session that is created.

Bo Carlsson

Hi, as with all binary only products this is verry hard to debug. The error message you get is probably valid for the Sonic developers but not for us since the session is created from the same connection as the consumer.

If you have the ability to do a test, the only think I can think of right now is that Sonic is expecting an XASession returned from StdServerSession and not a regular session. Could you test with something like this in StdServerSession.java:

public Session getSession() throws JMSException
{
if (xaSession != null)
return xaSession;
else
return session;
}

Else, try as Sonic why the error could possibly occur when the the two is actually created from the same connection.

//Peter

Thank you Peter, that did the trick! When the proper XASession is returned, SonicMQ stops whining.

Still things don't work but now I'm almost certain than Sonic are to blame. An exception is thrown in JBoss TxCapsule and my guess is that everything but Sonic stuff behaving alright.

I turned on the trace flag and saw:

[Container factory] TxCapsule.commit(): Entered, tx=XidImpl [FormatId=257, GlobalId=boca007nt4bb//0, BranchQual=] status=STATUS_ACTIVE
[Container factory] TxCapsule.commit(): Before completion done, tx=XidImpl [FormatId=257, GlobalId=boca007nt4bb//0, BranchQual=] status=STATUS_ACTIVE
[Container factory] endresources(0): state=1
[Container factory] TxCapsule.endResource(XidImpl [FormatId=257, GlobalId=boca007nt4bb//0, BranchQual=1]) entered: flag=67108864
[Container factory] java.lang.NullPointerException
[Container factory] at progress.message.jclient.Session.acknowledgeLastAsyncMsg(:834)
[Container factory] at progress.message.jclient.xa.fr.sk_(:233)
[Container factory] at progress.message.jclient.xa.XAResource.end(:248)
[Container factory] at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1129)
[Container factory] at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1187)
[Container factory] at org.jboss.tm.TxCapsule.commit(TxCapsule.java:311)
[Container factory] at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76)
[Container factory] at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:231)
[Container factory] at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:642)
[Container factory] at java.lang.Thread.run(Thread.java:484)

I wouldn't expect you to solve this, but would it be correct to assume that an appropriate XASession is found and used by JBoss but Sonic has a bad XA-implementation?

Bo Carlsson

Hi, nice that it worked the first step. Now we now that the XASession and the session returned from that is not the same in Sonic.

You might therefore have to add two more things.

In the run() method of StdServerSession there is this line:

session.run();

Change this to:

// run the session
if(xaSession != null)
xaSession.run();
else
session.run();

In StdServerSessionPool there is a long method named init(). Near the end of it is a line:

ses.setMessageListener(listener);

Change this to:

if (xaSes != null)
xaSes.setMessageListener(listener);
else
ses.setMessageListener(listener);

Could you please check if it works any better with this. This could be the reason their XAResource is not filled in as expected, perhaps.

//Peter