[
https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53650#action_53650
]
Cedric Neve commented on AMQ-2355:
----------------------------------
David, thanks for the comment.
About the code that you find suspicious in Weblogic, by using local references
(that later link to the ActiveMQ connector) we are enabling Weblogic to add
some services when accessing the JMS components. In this case, the most
important one is the transactionnal support. From what I have heard of the
people of Weblogic, the MDB has the following behaviour:
1 - It connects to the broker through the connection factory provided by the
connector.
2 - Since the connection factory does not implement
javax.jms.XAConnectionFactory, it cannot create a transaction with XA support.
(-> this is the issue, according to the Weblogic support; Sebastien (from
Weblogic support), please feel free to contradict me if I state this wrong)
3 - Once an access is made in the MDB to another JMS resource (to send a
message), Weblogic tries to enlist this operation in the existing transaction
(as you would expect of the TransactionManager). However, since we are talking
about two connection factories (one for the reception and one for the send), it
requires a transaction with XA support which he does not have in this case...
hence the error message.
David, you can look in the attached files the way we link to the resource
adapter. This has been checked by Fuse Support (thanks Daan) and works
perfectly with JBoss. The only changes that we did for Weblogic are:
- Adding the necessary weblogic-ejb-jar.xml with the elements comparable with
what is in the jboss.xml
- Adding the weblogic-ra.xml with the elements comparable with what is in the
activeMQ-jms-ds.xml (to declare the oubound queue and connection factory).
Once this will be working, I would be glad to contribute the Weblogic How-To
with the sample code comparable with the one found for JBoss since I found that
one very instructive. But first things first... it should work before we get to
document it for others to use ;-)
> 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), ActiveMQ 5.2.0 and
> Fuse ActiveMQ 5.3.0.2, ActiveMQ 5.2.0 and Fuse ActiveMQ 5.3.0.2 connector,
> Ubuntu 9.04
> Reporter: Cedric Neve
> Attachments: MDBTest.zip, weblogic-ra.xml
>
>
> 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.
