You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Cedric Neve (JIRA)" <ji...@apache.org> on 2009/08/17 13:52:36 UTC
[jira] Created: (AMQ-2355) 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"
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.
[jira] Commented: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53651#action_53651 ]
Cedric Neve commented on AMQ-2355:
----------------------------------
In case this is not clear by now, Weblogic support told us that, in order to fix this, we would only require a way to get a connection factory with XA support from the connector and available in the JNDI. It seems that JBoss gets one by default but this is not the case for Weblogic.
> 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53654#action_53654 ]
Cedric Neve commented on AMQ-2355:
----------------------------------
Some results after some extra testing:
When deploying the resource adapter, I get the following warnings:
<Aug 18, 2009 8:14:53 AM CEST> <Warning> <Connector> <BEA-190155> <Compliance checking/validation of the resource adapter /home/cedric/java/oracle11g/user_projects/domains/basic_domain/apps/activemq-rar-fuse.rar resulted in the following warnings:
The ra.xml <resourceadapter-class> class 'org.apache.activemq.ra.ActiveMQResourceAdapter' should implement java.io.Serializable but does not.>
<Aug 18, 2009 8:14:53 AM CEST> <Warning> <WorkManager> <BEA-002919> <Unable to find a WorkManager with name activemq-rar-fuse.rar. Dispatch policy activemq-rar-fuse.rar will map to the default WorkManager for the application activemq-rar-fuse>
I am not sure how these can affect the availability of the connector elements.
Based on the advise of Weblogic support, I added 3 test cases: The first one without transaction support, the second one without the EJB local references to the oubound connection factory and queue and the third one without the transaction support and without the EJB local references to the outbound JMS elements. The results of these test cases are below.
MDB with <trans-attribute>NotSupported</trans-attribute>: No exception at first in Weblogic, no exception in ActiveMQ, the message reception was acknowledged but there is nothing in the outband queue...
After a 46 seconds, a warning appeared in Weblogic (the first message shows you when I sent the message to launch the test case):
08:29:12,973 PERFORMANCE [MyAction] be.fgov.minfin.ccff.fwk.logging.internal.message.PerformanceMessageImpl: DESCRIPTION = Sending 1 message(s) of 100 byte(s) to ActiveMQ -> testQueue6, UID = 8cfa31f2-add8-3e19-95e5-66cd140ee100, DOMAIN = basic_domain, DURATION = 47, SERVER = AdminServer
<Aug 18, 2009 8:29:58 AM CEST> <Error> <JMSPool> <BEA-169805> <A pooled JMS connection is being closed because an error was detected on the connection: javax.jms.JMSException: [JMSPool:169819]There was an error with a resource pool used to pool JMS sessions: weblogic.common.resourcepool.ResourceDeadException: 0:javax.jms.IllegalStateException: The Connection is closed. Linked exception: weblogic.common.resourcepool.ResourceDeadException: 0:javax.jms.IllegalStateException: The Connection is closed>
MDB with no EJB local reference to JMS outbound elements: This worked :-) I got the message in the outbound queue. The rollback of the message when a Runtime exception occurs still needs to be tested though to make sure that we get the correct behaviour. This is already great news.
MDB with no EJB local reference to JMS outbound elements and with <trans-attribute>NotSupported</trans-attribute>: No exception in Weblogic but the following exception in the broker:
ERROR Service - Async error occurred: java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.activemq.broker.TransportConnection.processRemoveSession(TransportConnection.java:589)
at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:62)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:305)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:203)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185)
at java.lang.Thread.run(Thread.java:619)
The message is consummed in Weblogic and no message was added to the outbound queue.
I will put the updated weblogic-ra.xml and MDB test project online (attached to this case) so that you can inspect the changes I made to support these test cases.
Based on these results, I will also try the rollback scenarios with no EJB local references. I will provide the results as soon as I get them.
> 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cedric Neve updated AMQ-2355:
-----------------------------
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 (was: Weblogic 10.3.1 (aka Oracle 11g), Fuse ActiveMQ 5.3.0.2, Fuse ActiveMQ 5.3.0.2 RA, Ubuntu 9.04)
> 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.
[jira] Issue Comment Edited: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53657#action_53657 ]
Cedric Neve edited comment on AMQ-2355 at 8/18/09 12:23 AM:
------------------------------------------------------------
I added one more test:
- MDB with transaction support receives a message
- It sends a message to the outbound queue in its onMessage(...)
- It throws a RuntimeException
The expected behaviour is that the message will be redelivered 5 times and end up in the DLQ of ActiveMQ. Of course, no message should arrive in the outbound queue.
The behaviour that I notice is the same as the one for the runtime exception occuring in a simple reception of a message:
- An runtime exception is logged in Weblogic. (-> ok)
- The message reception is acknowledged (-> nok)
- and there is no redelivery (-> nok)
- The message arrives in the outbound queue (-> nok)
So... I think we progressed but we still do not have a correct behaviour in case a Runtime exception occurs. Any ideas how to achieve this in Weblogic ?
Based on these findings, I would currently advise not to use local references within Weblogic. This is very annoying for applications that need to be deployabled on both Weblogic and JBoss because the advise is to use local references for JBoss and those are referenced from the ejb-jar.xml which is common for both Weblogic and JBoss (and any other application server for that matter). But at least there is a solution to make it work (except the rollback) which is already an improvement.
was (Author: cedneve):
I added one more test:
- MDB with transaction support receives a message
- It sends a message to the outbound queue in its onMessage(...)
- It throws a RuntimeException
The expected behaviour is that the message will be redelivered 5 times and end up in the DLQ of ActiveMQ. Of course, no message should arrive in the outbound queue.
The behaviour that I notice is the same as the one for the runtime exception occuring in a simple reception of a message:
- An runtime exception is logged in Weblogic. (-> ok)
- The message reception is acknowledged (-> nok) and there is no redelivery (-> nok)
- The message arrives in the outbound queue (-> nok)
So... I think we progressed but we still do not have a correct behaviour in case a Runtime exception occurs. Any ideas how to achieve this in Weblogic ?
Based on these findings, I would currently advise not to use local references within Weblogic. This is very annoying for applications that need to be deployabled on both Weblogic and JBoss because the advise is to use local references for JBoss and those are referenced from the ejb-jar.xml which is common for both Weblogic and JBoss (and any other application server for that matter). But at least there is a solution to make it work (except the rollback) which is already an improvement.
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "sebastien (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53820#action_53820 ]
sebastien commented on AMQ-2355:
--------------------------------
Thanks David your answer.
I just opened a Bug on Oracle side and I hope we will be able progress soon.
Bug reference 8843814.
Sincerely
Sébastien
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53647#action_53647 ]
David Jencks commented on AMQ-2355:
-----------------------------------
I don't know anything about weblogic. For instance, they might have non-spec support for jms that is getting in the way of using activemq as a j2ca compliant inbound and outbound resource adapter, or you might have deployed the activemq connectivity in some way that does not use the activemq resource adapter. I'm extremely suspicious of this:
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)
which looks to me as if weblogic is not using the j2ca support for xa transactions which would be enlisting the connection in the xa transaction well before your app tried to send a message, but rather expecting an XASession which is never going to be visible or available in a j2ca connector.
If you are deploying as a j2ca resource adapter, you should be getting an org.apache.activemq.ra.ActiveMQConnectionFactory instance from a jndi lookup (or some wrapped or proxied version of this class). All the xa support is handled behind the scenes in the weblogic connection manager and the org.apache.activemq.ra.ActiveMQManagedConnectionFactory which supplies an XAResource to the transaction management internals. Your code should definitely never see anything related to xa support and the means of enlisting in an xa transaction should not be visible to a session obtained from a connection obtained from the connection factory.
> 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cedric Neve updated AMQ-2355:
-----------------------------
Attachment: weblogic-ra.xml
Weblogic RA deployment descriptor for the tests with no transaction support and no EJB local references to the JMS outbound elements.
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "sebastien (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53660#action_53660 ]
sebastien commented on AMQ-2355:
--------------------------------
Hi,
i am Sebastien and I am part of the frontilne team of Weblogic support.
Thanks David for your explanations.
I am currently checking how Weblogic container can force the connector to retrieve an XAConnection. Maybe some attributes specified in the descriptors are skipped if there is an issue on this side.
May you tell me what we need to pass to the connector to get such XA object?
Also I am wondering why there is no org.apache.activemq.ra.ActiveXAMQConnectionFactory that can expose directly an XAConnectionFactory?
Thanks
Sebastien
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53658#action_53658 ]
David Jencks commented on AMQ-2355:
-----------------------------------
I'm not in a position to research deployment of resource adapters into weblogic. However, the comments from oracle support indicate to me that you may not be deploying actiivemq as a j2ca 1.5 resource adapter, or the support personell don't understand how it works. Here's a brief attempt at a descriptions:
Your app looks up a connection facotry cf in jndi. Your app asks the cf for a connection. The cf asks a connection manager for a suitable ManagedConnection, which may be obtained from a pool or from a ManagedConnectionFactory. Once the ManagedConnection is obtained, the transaction machinery gets an XAResource from it. If there is an existing jta transaction, the managed connection is immediately enrolled in it. If a jta trahsaction is started later (such as through UserTransaction.begin()) then all the managed connections in use are enrolled in the jta transaction.
After the ManagedConnection is obtained, a Connection is obtained from it. This is what your app gets. It has some locatl transaction support, but jta transaction management is completely invisible to the connection object.
Since IIUC weblogic is either j2ee 1.4 or javaee5 certified, it's required to support deployment of resource adapters, including activemq-rar, in this way. Before j2ee 1.4 there was an attempt to provide a way to deploy jms provders in some other way that I don't recall very well. I think that the XASession is supposed to support this deployment method. I don't recommend it. Perhaps you have somehow managed to deploy activemq in this way, in which case the connection pooling and jta transaction support would most likely be unavailable.
I'm glad to see that whether or not any of the code I wrote for jboss remains, their j2ca support still works.
If you don't have any other resource managers involved in your mdb, activemq has an config-property to make it so an mdb will use the same connection for inbound and outbound messages to an mbd. This would theorectially remove the need for an xa transaction, although I don't know how weblogic would detect this unless it was using the XAResource from teh ManagedConnection, in which case you would not have this problem in the first place.
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53670#action_53670 ]
David Jencks commented on AMQ-2355:
-----------------------------------
Hi Sebastian,
Perhaps we could use fully qualiified class names to avoid misunderstandings.
The XAConnectionFactory implementation is not part of the j2ca connector, it's in activemq core.
org.apache.activemq.ActiveMQXAConnectionFactory
I've never used it.
Apparently weblogic can support jms both using the old-fashined XAConnectionFactory as well as through a j2ca connector (the latter is required by the j2ca support). Out of curiousity, why would one choose the XAConnectionFactory approach?
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cedric Neve updated AMQ-2355:
-----------------------------
Attachment: weblogic-ra.xml
Weblogic RA deployment descriptor to add in the META-INF folder of the connector. The rest of the configuration can be the default one.
> 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
> 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53657#action_53657 ]
Cedric Neve commented on AMQ-2355:
----------------------------------
I added one more test:
- MDB with transaction support receives a message
- It sends a message to the outbound queue in its onMessage(...)
- It throws a RuntimeException
The expected behaviour is that the message will be redelivered 5 times and end up in the DLQ of ActiveMQ. Of course, no message should arrive in the outbound queue.
The behaviour that I notice is the same as the one for the runtime exception occuring in a simple reception of a message:
- An runtime exception is logged in Weblogic. (-> ok)
- The message reception is acknowledged (-> nok) and there is no redelivery (-> nok)
- The message arrives in the outbound queue (-> nok)
So... I think we progressed but we still do not have a correct behaviour in case a Runtime exception occurs. Any ideas how to achieve this in Weblogic ?
Based on these findings, I would currently advise not to use local references within Weblogic. This is very annoying for applications that need to be deployabled on both Weblogic and JBoss because the advise is to use local references for JBoss and those are referenced from the ejb-jar.xml which is common for both Weblogic and JBoss (and any other application server for that matter). But at least there is a solution to make it work (except the rollback) which is already an improvement.
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "sebastien (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53691#action_53691 ]
sebastien commented on AMQ-2355:
--------------------------------
Hi David,
Q - why would one choose the XAConnectionFactory approach?
A - In fact, I am comparing ActiveMQ to Tibco or IBM MQ. These two JMS providers are exposing an XAConnectionFactory so we do not face this issue. However with these two providers we do not work with adapters but we acces the resoucre via JNDI.
Regarding ActiveMQ, I would like to clarify one point :
- How is it possible that the ActiveMQ adapter returns an XASession object? What info should WLS container pass to the adapter to get such object?
It will help to understand what is missing in WLS code if there is an issue on our side.
- Or, do you consider that we should work with nonXA objects and WLS will emulate the 2PC?
Thanks
Sébastien
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cedric Neve updated AMQ-2355:
-----------------------------
Attachment: MDBTest.zip
MDBTests without transaction support and with no local EJB references to the outbound JMS elements
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53644#action_53644 ]
Cedric Neve commented on AMQ-2355:
----------------------------------
I just finished testing with ActiveMQ 5.2.0 (broker and connector).
I am getting the same exceptions.
When sending a message to testQueue2 (reception rollback test):
14:04:14,940 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)
With no redelivery and an acknowledged message.
For the sending in an MDB with transaction support (sent message to testQueue4):
<Aug 17, 2009 2:11:18 PM CEST> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "600" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@13646d1", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
Thread-14 "[STUCK] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" <alive, in native, suspended, waiting, priority=1, DAEMON> {
-- Waiting for notification on: java.lang.Object@4504c0d[fat lock]
java.lang.Object.wait(Object.java:???)
org.apache.activemq.transport.failover.FailoverTransport.oneway(FailoverTransport.java:387)
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:39)
^-- Holding lock: java.lang.Object@4504c2e[thin lock]
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:57)
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1225)
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1216)
org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1626)
^-- Holding lock: java.lang.Object@139e435[thin lock]
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:196)
org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:269)
weblogic.deployment.jms.WrappedMessageProducer.send(WrappedMessageProducer.java:161)
weblogic.deployment.jms.JMSSessionPoolTester.sendQueueMessage(JMSSessionPoolTester.java:352)
weblogic.deployment.jms.JMSSessionPoolTester.timerExpired(JMSSessionPoolTester.java:291)
^-- Holding lock: weblogic.deployment.jms.JMSSessionPoolTester@138fef3[thin lock]
weblogic.timers.internal.TimerImpl.run(TimerImpl.java:253)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:198)
weblogic.work.ExecuteThread.run(ExecuteThread.java:165)
}
Which is different from before. At that point, the MDB is stuck and the message reception has not been acknowledged.
After restarting the server, I get the same exception as with fuse-5.3.0.2:
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)
> 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
> 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.
[jira] Commented: (AMQ-2355) 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"
Posted by "sebastien (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54565#action_54565 ]
sebastien commented on AMQ-2355:
--------------------------------
Hi David, Hi Cédric
We have made some progress on Oracle side. There is an issue when using Oracle JMS Wrapper (including with resource-ref) and the connector. When the application is deployed, XA resource is checked and it is considered as non XA compliant.
A workaround has been provided to avoid this behavior:
In ejb-jar.xml, we must declare the connection factory resource as java.lang.Object (res-type) instead of javax.jms.QueueConnectionFactory
Once this first issue was workarounded, we found a new issue related to JTA and how the container handles it. A new Bug has been created (Bug8970918) to track it.
Our MDB is consuming a message from ActiveMQ, then sends a new message to an outbound queue hosted on ActiveMQ too. For test purpose, we throw a RuntimeException after the MDB sends this new message. In that case, in order to make the transaction work correctly, we need to invoke setRollbackOnly. However, based on the specifications, it is not required since RuntimeException is a system exception. If you do not specified setRollbackOnly then the first message is dequeued and the second message is sent to the otbound queue.
Sample code to workaround the transaction issue :
onMessage(){
try{
//your business process here
}catch(Exception e){
messageDrivenContext.setRollbackOnly();
throw new RuntimeException("test");
}
}
Thanks for your help on this ! I believe this thread can be closed.
Sébastien
> 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, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Bruce Snyder (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bruce Snyder updated AMQ-2355:
------------------------------
Fix Version/s: 5.5.0
(was: 5.4.1)
> 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
> Fix For: 5.5.0
>
> Attachments: MDBTest.zip, MDBTest.zip, weblogic-ra.xml, 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.
[jira] Updated: (AMQ-2355) 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"
Posted by "Cedric Neve (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cedric Neve updated AMQ-2355:
-----------------------------
Attachment: MDBTest.zip
MDBTest project (Maven2)
> 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
> 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.