[
https://issues.apache.org/activemq/browse/AMQ-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53922#action_53922
]
David Jencks commented on AMQ-2346:
-----------------------------------
Making ENDED_XA_TRANSACTION_CONTEXTS static in TransactionContext makes the
test pass for me. This variable doesn't make any sense unless it's static, as
otherwise the only possible TransactionContext in the list is "this".
I'm not thrilled with introducing a static, in an osgi environment it would be
better to have a service, but it seems like the best solution in a non-osgi
environment.
Unfortunately I'm seeing a new problem, apparently a race condition between
closing a connection and starting a new connection and setting clientId.
Adding a Thread.sleep(10) to JmsTransactionTestSupport reconnect sidesteps this
problem...
Tests run: 17, Failures: 0, Errors: 15, Skipped: 0, Time elapsed: 2.022 sec <<<
FAILURE!
testReceiveTwoThenCloseConnection(org.apache.activemq.ra.JmsXARollback2CxTransactionTest)
Time elapsed: 1.124 sec <<< ERROR!
javax.jms.InvalidClientIDException: Broker: localhost - Client:
org.apache.activemq.test.JmsResourceProvider already connected from
vm://localhost#8
at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:216)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:77)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:82)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:89)
at
org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:686)
at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:134)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:308)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:182)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at
org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:205)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:613)
> in managed environment, 2 connections/session, UserTransaction, transaction
> management gets confused
> ----------------------------------------------------------------------------------------------------
>
> Key: AMQ-2346
> URL: https://issues.apache.org/activemq/browse/AMQ-2346
> Project: ActiveMQ
> Issue Type: Bug
> Components: JCA Container
> Affects Versions: 5.3.0
> Reporter: David Jencks
> Assignee: Gary Tully
> Fix For: 5.3.0
>
>
> In geronimo we're seeing an intermittent tck problem that seems to relate to
> a situation where there are:
> -- a BMT stateless session ejb
> -- two connections (I think these get shared to the same ManagedConnection)
> -- two sessions
> -- tx control through UT
> -- send a message in one tx
> -- receive message in a tx that is rolled back
> -- receive message in a tx that is committed
> In a public test case I'm seeing that the session proxies get confused about
> whether there is an active transaction. This doesn't happen all the time but
> with a few repititions it happens consistently.
> See GERONIMO-4784
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
