Sending a message from an MDB in Weblogic 10.3.1: "Unable to use a wrapped JMS
session in the transaction because two-phase commit is not available"
----------------------------------------------------------------------------------------------------------------------------------------------------
Key: AMQ-2355
URL: https://issues.apache.org/activemq/browse/AMQ-2355
Project: ActiveMQ
Issue Type: Bug
Components: Connector
Affects Versions: 5.3.0
Environment: Weblogic 10.3.1 (aka Oracle 11g), Fuse ActiveMQ 5.3.0.2,
Fuse ActiveMQ 5.3.0.2 RA, Ubuntu 9.04
Reporter: Cedric Neve
I am doing ActiveMQ validation tests for our client and we have encountered a
bug that prevents us from using it with Weblogic. The issue concerns the XA
support of ActiveMQ within that application server. With JBoss, the same test
succeeded so this is more an integration problem of the RA with Weblogic than a
real bug with the connector.
I will attach the test project but here is the scenario:
1) A message is sent to testQueue4 (that is hosted by an ActiveMQ broker).
2) An MDB, deployed within Weblogic and listening on the queue through the
connector (and the deployment descriptors of the ejb), receives the message and
starts processing it within a transaction (
<transaction-type>Container</transaction-type>,
<trans-attribute>Required</trans-attribute>).
3) The processing implies the sending of a message on testQueue5 that is
configured within the weblogic-ra.xml and through a ConnectionFactory that is
also configured in that file (and accessed through the EJB local references).
4) The send fails with the following stacktrace:
javax.jms.JMSException: [JMSPool:169822]Unable to use a wrapped JMS session in
the transaction because two-phase commit is not available
at
weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions.java:22)
at
weblogic.deployment.jms.WrappedTransactionalSession.enlistInExistingTransaction(WrappedTransactionalSession.java:153)
at
weblogic.deployment.jms.WrappedTransactionalSession.enlistInTransaction(WrappedTransactionalSession.java:206)
at
weblogic.deployment.jms.WrappedMessageProducer.send(WrappedMessageProducer.java:136)
at
be.fgov.minfin.ccff.fwk.application.SendingMDB.sendJMS(SendingMDB.java:77)
at
be.fgov.minfin.ccff.fwk.application.SendingMDB.onMessage(SendingMDB.java:36)
at
be.fgov.minfin.ccff.fwk.application.SendingMDB_7x60v6_MDOImpl.onMessage(SendingMDB_7x60v6_MDOImpl.java:49)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
I am in contact with Fuse support and Oracle support about this case but we are
stuck at the moment and no one seems to be able to fix this. So this is a cry
out to the community to help us solve this issue and getter a better Weblogic
support of ActiveMQ.
I will reproduce this with 5.2 (ActiveMQ version, not Fuse) and will post a
comment about that as soon as it is done. I do not think it is Fuse specific at
this time.
Here is what I figured out so far:
- When using EJB local references, the elements that are accessed (in this case
the connection factory and the queue) should be enlisted in the transaction
(hence the elistInExistingTransaction method call in the stacktrace).
- This also happens when we are using a Foreign JNDI server to make the
outbound connections to ActiveMQ instead of the weblogic-ra.xml.
- Based on what the Oracle support told us, in debug mode, they saw that the
are retrieving ActiveMQConnectionFactory instance and not an
ActiveMQXAConnectionFactory instance. This would confirm that the XA support is
not present for the Connection Factory returned by the Connector.
So, to fix this, we would wish to know how we could instruct the connector to
return an XA connection factory instead of the basic connection factory. It
seems that the problem is not only present for sending but is also present for
reception:
1) Send a message to testQueue2
2) The message is received on an MDB deployed within WL 10.3.1 with transaction
support and using local EJB references
3) We through a RuntimeException in the onMessage() to test the rollback and
receive the following exception (which is fine for us):
13:47:29,756 ERROR [ActiveMQSession] error dispatching message:
javax.ejb.EJBException: Unexpected exception in
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMessage():
java.lang.RuntimeException: Rollback to DLQ test
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMessage(ReceptionRollbackToDLQMDB.java:23)
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
; nested exception is: java.lang.RuntimeException: Rollback to DLQ test
java.lang.RuntimeException: Rollback to DLQ test
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMessage(ReceptionRollbackToDLQMDB.java:23)
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
javax.ejb.EJBException: Unexpected exception in
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMessage():
java.lang.RuntimeException: Rollback to DLQ test
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMessage(ReceptionRollbackToDLQMDB.java:23)
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
; nested exception is: java.lang.RuntimeException: Rollback to DLQ test
at
be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:93)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
4) The message is not redelivered even though the default behaviour is
documented as provoking 5 deliveries before sending the message to the DLQ.
Here, the message seems to be acknowledged just as if the message reception was
not in a transaction.
We are not using the "useRAManagedTransaction" activation config property since
we want the transaction to be container managed.
I will attach the MDB project and the weblogic-ra.xml for this case to be
reproductible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
