Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Tue, 9 Oct 2012 07:34:03 +0000 (UTC)
From: "Sebastian J. (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <963335251.13370.1349768043529.JavaMail.jiratomcat@arcas>
Subject: [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"
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AMQ-2355?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D134721=
99#comment-13472199 ]=20

Sebastian J. commented on AMQ-2355:
-----------------------------------

Thanks S=C3=A9bastien for the Feedback.
I just want to contribute that this workaround also applies for Spring/WAR =
deployments (and also the same error occurs).
Setting in web.xml
{quote}In ejb-jar.xml, we must declare the connection factory resource as j=
ava.lang.Object (res-type) instead of javax.jms.QueueConnectionFactory
{quote} sends the message.
               =20
> Sending a message from an MDB in Weblogic 10.3.1: "Unable to use a wrappe=
d JMS session in the transaction because two-phase commit is not available"
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------
>
>                 Key: AMQ-2355
>                 URL: https://issues.apache.org/jira/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.x
>
>         Attachments: MDBTest.zip, MDBTest.zip, weblogic-ra.xml, weblogic-=
ra.xml
>
>
> I am doing ActiveMQ validation tests for our client and we have encounter=
ed a bug that prevents us from using it with Weblogic. The issue concerns t=
he XA support of ActiveMQ within that application server. With JBoss, the s=
ame test succeeded so this is more an integration problem of the RA with We=
blogic 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 th=
e connector (and the deployment descriptors of the ejb), receives the messa=
ge and starts processing it within a transaction ( <transaction-type>Contai=
ner</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 referen=
ces).
> 4) The send fails with the following stacktrace:
> javax.jms.JMSException: [JMSPool:169822]Unable to use a wrapped JMS sessi=
on in the transaction because two-phase commit is not available
> =09at weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions=
.java:22)
> =09at weblogic.deployment.jms.WrappedTransactionalSession.enlistInExistin=
gTransaction(WrappedTransactionalSession.java:153)
> =09at weblogic.deployment.jms.WrappedTransactionalSession.enlistInTransac=
tion(WrappedTransactionalSession.java:206)
> =09at weblogic.deployment.jms.WrappedMessageProducer.send(WrappedMessageP=
roducer.java:136)
> =09at be.fgov.minfin.ccff.fwk.application.SendingMDB.sendJMS(SendingMDB.j=
ava:77)
> =09at be.fgov.minfin.ccff.fwk.application.SendingMDB.onMessage(SendingMDB=
.java:36)
> =09at be.fgov.minfin.ccff.fwk.application.SendingMDB_7x60v6_MDOImpl.onMes=
sage(SendingMDB_7x60v6_MDOImpl.java:49)
> =09at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.on=
Message(MessageEndpointProxy.java:123)
> =09at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpoi=
ntProxy.java:64)
> =09at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
> =09at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java=
:169)
> =09at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
> =09at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
> =09at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
> =09at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTun=
ingWorkManagerImpl.java:516)
> =09at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> =09at 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 bet=
ter 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 spec=
ific at this time.
> Here is what I figured out so far:
> - When using EJB local references, the elements that are accessed (in thi=
s case the connection factory and the queue) should be enlisted in the tran=
saction (hence the elistInExistingTransaction method call in the stacktrace=
).
> - This also happens when we are using a Foreign JNDI server to make the o=
utbound 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 ActiveMQXA=
ConnectionFactory instance. This would confirm that the XA support is not p=
resent for the Connection Factory returned by the Connector.
> So, to fix this, we would wish to know how we could instruct the connecto=
r to return an XA connection factory instead of the basic connection factor=
y. It seems that the problem is not only present for sending but is also pr=
esent for reception:
> 1) Send a message to testQueue2
> 2) The message is received on an MDB deployed within WL 10.3.1 with trans=
action 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:=20
> javax.ejb.EJBException: Unexpected exception in be.fgov.minfin.ccff.fwk.a=
pplication.ReceptionRollbackToDLQMDB.onMessage():
> java.lang.RuntimeException: Rollback to DLQ test
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMes=
sage(ReceptionRollbackToDLQMDB.java:23)
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4ws=
g_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
> =09at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.on=
Message(MessageEndpointProxy.java:123)
> =09at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpoi=
ntProxy.java:64)
> =09at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
> =09at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java=
:169)
> =09at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
> =09at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
> =09at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
> =09at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTun=
ingWorkManagerImpl.java:516)
> =09at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> =09at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> ; nested exception is: java.lang.RuntimeException: Rollback to DLQ test
> java.lang.RuntimeException: Rollback to DLQ test
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMes=
sage(ReceptionRollbackToDLQMDB.java:23)
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4ws=
g_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
> =09at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.on=
Message(MessageEndpointProxy.java:123)
> =09at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpoi=
ntProxy.java:64)
> =09at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
> =09at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java=
:169)
> =09at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
> =09at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
> =09at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
> =09at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTun=
ingWorkManagerImpl.java:516)
> =09at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> =09at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> javax.ejb.EJBException: Unexpected exception in be.fgov.minfin.ccff.fwk.a=
pplication.ReceptionRollbackToDLQMDB.onMessage():
> java.lang.RuntimeException: Rollback to DLQ test
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB.onMes=
sage(ReceptionRollbackToDLQMDB.java:23)
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4ws=
g_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:49)
> =09at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.on=
Message(MessageEndpointProxy.java:123)
> =09at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpoi=
ntProxy.java:64)
> =09at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
> =09at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java=
:169)
> =09at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
> =09at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
> =09at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
> =09at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTun=
ingWorkManagerImpl.java:516)
> =09at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> =09at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> ; nested exception is: java.lang.RuntimeException: Rollback to DLQ test
> =09at be.fgov.minfin.ccff.fwk.application.ReceptionRollbackToDLQMDB_dz4ws=
g_MDOImpl.onMessage(ReceptionRollbackToDLQMDB_dz4wsg_MDOImpl.java:93)
> =09at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.on=
Message(MessageEndpointProxy.java:123)
> =09at org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpoi=
ntProxy.java:64)
> =09at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:766)
> =09at org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java=
:169)
> =09at weblogic.connector.security.layer.WorkImpl.runIt(WorkImpl.java:108)
> =09at weblogic.connector.security.layer.WorkImpl.run(WorkImpl.java:44)
> =09at weblogic.connector.work.WorkRequest.run(WorkRequest.java:95)
> =09at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTun=
ingWorkManagerImpl.java:516)
> =09at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
> =09at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> 4) The message is not redelivered even though the default behaviour is do=
cumented as provoking 5 deliveries before sending the message to the DLQ. H=
ere, 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.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira