Issue Details (XML | Word | Printable)

Key: GLASSFISH-9824
Type: Bug Bug
Status: Resolved Resolved
Resolution: Incomplete
Priority: Critical Critical
Assignee: Nigel Deakin
Reporter: jthoennes
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
glassfish

DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId

Created: 29/Sep/09 08:41 AM   Updated: 25/Jun/12 09:08 AM   Resolved: 19/Oct/09 04:07 AM
Component/s: jms
Affects Version/s: v2.1
Fix Version/s: V3

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive Reproduce-DXAR-Error.zip (152 kB) 29/Sep/09 08:59 AM - jthoennes
2. Text File server.log (408 kB) 29/Sep/09 09:44 AM - jthoennes

Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 9,824
Tags:
Participants: houghvw, jthoennes, Nigel Deakin and Satish Kumar


 Description  « Hide

This error appears in the Glassfish log:

[#|2009-09-29T17:33:31.127+0200|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=p:
thread-pool-1; w: 5;|DXAR:start():Warning:Received diff Xid for open
txnId:switching transactionId:
DXAR
Xid=616C636F722C7365727665722C50333730302C010B000000BB566F06616C636F722C7365727665722C5033373030
DXAR TXid=1776991138030900224
got Xid=null
got TXid=1776991138030909184|#]

Afterwards, this error shows up:
[#|2009-09-29T17:33:31.134+0200|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=19;_ThreadName=p:
thread-pool-1; w: 6;java.lang.RuntimeException:
javax.transaction.xa.XAException;prepare;_RequestID=f0001a51-e07e-4a21-91de-e1de0877be9c;|JTS5031:
Exception [java.lang.RuntimeException: javax.transaction.xa.XAException] on
Resource [prepare] operation.|#]

[#|2009-09-29T17:33:31.136+0200|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=19;_ThreadName=p:
thread-pool-1; w: 6;_RequestID=f0001a51-e07e-4a21-91de-e1de0877be9c;|JTS5068:
Unexpected error occurred in rollback
java.lang.NullPointerException
at
com.sun.messaging.jmq.jmsserver.data.handlers.TransactionHandler.doRollback(TransactionHandler.java:1200)
at
com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.rollbackTransaction(ProtocolImpl.java:683)
at
com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.rollbackTransaction(IMQDirectService.java:1805)
at com.sun.messaging.jms.ra.DirectXAResource.rollback(DirectXAResource.java:533)
at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:194)
at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:311)
at
com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1049)
at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2297)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:410)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at
com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
at
com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1003)
at
com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:398)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3817)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3596)
at
com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1226)
at
com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1197)
at
com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:79)
at
com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:139)
at $Proxy73.afterDelivery(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:324)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)

#]

This can be reproduced by the attached NB project, were two MDB process messages
and route them using a given MessageRouterBean.



jthoennes added a comment - 29/Sep/09 08:59 AM

Created an attachment (id=3341)
NetBeans project with EAR file to reproduce this issue


jthoennes added a comment - 29/Sep/09 09:44 AM

Created an attachment (id=3342)
server.log showing a run of the NB project


jthoennes added a comment - 29/Sep/09 09:51 AM

Nigel, here is the GF issue you requested in OpenMQ forum thread:

http://forums.sun.com/thread.jspa?threadID=5407905


jthoennes added a comment - 30/Sep/09 03:55 AM

In order to run the provided NB project test case, please create these JMS
resources in the Glassfish server:

  • Connection Factories
  • ConnectionFactory
  • Destination Resources
  • MessageProcessor01 (Queue)
  • MessageProcessor02 (Queue)

Satish Kumar added a comment - 30/Sep/09 06:16 PM
      • Issue 9825 has been marked as a duplicate of this issue. ***

Satish Kumar added a comment - 06/Oct/09 02:48 AM

Reassiging the issue to Nigel as per our discussion last week to see if this
issue is relevant for GF v3...


Nigel Deakin added a comment - 06/Oct/09 08:36 AM

These warnings and errors are a consequence of the application using MQ in an
incorrect manner.

The problem is the stateless session bean MessageRouterBean. This has a business
method sendMessage() which sends a message to a queue, using a connection and
session (provided by the resource adapter) cached in each bean instance.

The bean method sendMessage() is called from various places, including the
message-driven bean MessageProcessor01Bean.

Because sendMessage() is called from multiple MDB instances, a given session
bean instance will be called by a succession of different threads.

This violates the JMS restriction that a session object may only be used by a
single thread at a time.

Normal session bean behaviour means that the sendMessage() method is only called
on a given session bean instance by one thread at a time. After this method
returns, it becomes available for use by a different thread.

This is, however, invalid as even after the sendMessage() returns, the session
object remains associated with the calling thread's transaction until the
transaction is committed at some later time. As a consequence, a subsequent call
to sendMessage() may find itself trying to use a session object that is still
being used by some other thread/

The error is detected by the DirectXAResource object, causes the message
"DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId"
and subsequent errors.

The fix is to change the stateless session bean MessageRouterBean so that the
business method sendMessage() creates a connection and session, sends the
message, and immediately closes the connection and session. Note that this
change will not have any noticeable effect on performance since the connection
is actually pooled (and in any case the creation of connections and sessions
when using EMBEDDED mode is very fast).

Setting resolution as "INVALID"


jthoennes added a comment - 14/Oct/09 09:33 AM

Thanks, Nigel, for the detailed explanation.

But what happens when I close a connection while a XA transaction is going on?
Will that cause any issues?

I want be sure to avoid issues by creating and closing the connection locally in
the session bean: If the method is called from another bean, e.g. Message Driven
Bean inside a larger transaction, exactly this could happen.

In addition, is there any way to block stateless session beans until all
associated transactions are done?

Thanks, Jörg


Nigel Deakin added a comment - 19/Oct/09 04:07 AM

> But what happens when I close a connection while a XA transaction is going on?
> Will that cause any issues?

It should not; closing the connection after you've finished using it is the
recommended technique.

The connection object you're working with is actually a wrapper provided by the
JMS resource adapter which wraps the underlying JMS connection. When you call
connecton.close() on this wrapper object, the underlying connection isn't really
closed but remains active. When the transaction is committed the underlying
connection remains open but is returned to a pool and becomes available for use
by a subsequent call to createConnection().

> is there any way to block stateless session beans until all
> associated transactions are done?

I don't think so with Glassfish.

The general advice is: close the session and connection as soon as you no longer
need them and let the resource adapter look after the lifecycle of the
underlying resources. The pooling provided by the resource adapter is intended
to make it unnecessary for the application to cache transactional resources.


houghvw added a comment - 21/Jun/12 03:31 PM

Hi,

We are currently on glassfish 2.1 and are experiencing transaction related issues that seems to be related to this issue. The only error we see in the log is "Warning:Received diff Xid for open... "

Would it be possible to give more detail with regards to the resolution.

It is not possible for us to upgrade to glassfish v3 at this stage. Is there any patch available for v2 that might include this fix?

Any help will be much appreciated.

Regards


jthoennes added a comment - 25/Jun/12 09:08 AM

In reply to comment #10:
> We are currently on glassfish 2.1 and are experiencing transaction related
> issues that seems to be related to this issue. The only error we see in the log
> is "Warning:Received diff Xid for open... "
>
> Would it be possible to give more detail with regards to the resolution.

Comment 7 of Nigel Deakin explains this issue in very much detail. Which point is unclear to you?

> It is not possible for us to upgrade to glassfish v3 at this stage. Is there any
> patch available for v2 that might include this fix?

Unless you have commercial Glassfish support (and even then I guess) you will not get any patch for a GF 2.1.
Please avoid caching of JMS connection in stateless beans by any means.

Cheers, Jörg