-
Bug
-
Resolution: Done
-
Blocker
-
None
-
AMQ 7.1.0.GA
-
None
-
-
ARTEMIS-2144
The following exception can be seen in the server log file:
2018-10-17 15:29:34,695 ERROR [org.apache.activemq.artemis.ra] (Thread-40 (ActiveMQ-client-global-threads)) AMQ154004: Failed to deliver message: javax.resource.spi.ApplicationServerInternalException: Failed to begin transaction at org.springframework.jca.endpoint.AbstractMessageEndpointFactory$AbstractMessageEndpoint.beforeDelivery(AbstractMessageEndpointFactory.java:221) at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:293) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: javax.transaction.NotSupportedException: WFTXN0001: A transaction is already in progress at org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:60) at org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:54) at org.springframework.transaction.jta.JtaTransactionManager.createTransaction(JtaTransactionManager.java:1199) at org.springframework.jca.endpoint.AbstractMessageEndpointFactory$TransactionDelegate.beginTransaction(AbstractMessageEndpointFactory.java:312) at org.springframework.jca.endpoint.AbstractMessageEndpointFactory$AbstractMessageEndpoint.beforeDelivery(AbstractMessageEndpointFactory.java:218)
Based on ht log files it seems that ActiveMQMessageHandler starts (and thus associates to the Thread) a tx via AbstractMessageEndpointFactory$AbstractMessageEndpoint.beforeDelivery, but because the subsequent enlistResource/setTansactionTimeout under the same spring library call fails it incorrectly assumes the begin itself failed and does not subsequently call afterDelivery, which is where the tx would normally be dissociated i.e. cleaned up. Since a thread can have at most one associated tx, the failed but still associated tx thereafter obstructs creation of any new tx on the same thread.
- causes
-
-
- Closed
-
