[
https://issues.apache.org/jira/browse/ARTEMIS-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428347#comment-17428347
]
Justin Bertram commented on ARTEMIS-3526:
-----------------------------------------
You're seeing the expected behavior.
An XA transaction that has been prepared but not committed is typically
referred to as "in doubt". XA transactions that are in doubt are held by the
broker until they can be recovered either by the original transaction manager
(e.g. through some automated recovery process) or administratively via the
management API. It's best for the original transaction manager to perform the
recovery as it is able to communicate with _all_ the resource managers involved
in the XA transaction and make the appropriate decision to either commit or
rollback. That said, ActiveMQ Artemis provides a handful of management methods
to deal with XA transactions in a "heuristic" way. These management methods are
heuristic in that they are _unilateral_ decisions that affect the outcome of
transactions. Heuristic administrative actions may break the atomicity of
transactions if the administrative action differs from what was initially
chosen by the original transaction manager.
* {{listPreparedTransactions()}} - List all the prepared transaction, sorted by
date, oldest first
* {{listPreparedTransactionDetailsAsJSON()}} - List all the prepared
transaction, sorted by date, oldest first, with details, in JSON format
* {{listPreparedTransactionDetailsAsHTML()}} - List all the prepared
transaction, sorted by date, oldest first, with details, in HTML format
* {{listHeuristicComittedTransactions()}} - List transactions which have been
heuristically committed
* {{listHeuristicRolledBackTransactions()}} - List transactions which have been
heuristically rolled back
* {{commitPreparedTransaction(String)}} - Heuristically commits a prepared
transaction.
* {{rollbackPreparedTransaction(String)}} - Heuristically rolls back a prepared
transaction.
The broker even ships with an example demonstrating how these methods can be
used. See {{examples/features/standard/xa-heuristic}}.
> Messages get stuck in delivering status on a queue.
> ---------------------------------------------------
>
> Key: ARTEMIS-3526
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3526
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.18.0
> Reporter: Jelmer
> Priority: Major
>
> It seems that not "well behaved" consumers can cause messages to get stuck in
> a delivering-status on a queue. It seems like the following can occur (sample
> code follows):
> 1) Create a xa-connection/xa-session to an Artemis broker
> 2) Create a consumer on a queue on this Broker.
> 3) Start the "xa-transaction"
> 4) Consume a message
> 5) End the "xa-transaction"
> 6) Initiate a "xa-prepare" for the two-phase commit
> 7) DO NOT initiate a "xa-commit" (the consumer is not wel behaved or gets
> killed half way through the process etc.).
>
> In code (partial and based on the XAReceiveExample from the Artemis-samples):
> {code:java}
> try (final XAConnection xaconnection = createXAConnection(xacf);
> final XASession xaSession = createXASession(xaconnection)) {
> final MessageConsumer consumer = xaSession.createConsumer(queue);
> final Xid xid = createXid();
> final XAResource xaRes = xaSession.getXAResource();
> xaRes.start(xid, XAResource.TMNOFLAGS);
> final Message message = consumer.receive(2000);
> System.out.println("MESSAGE CONSUMED [" + message.getJMSMessageID() + "]");
> xaRes.end(xid, XAResource.TMSUCCESS);
> xaRes.prepare(xid);
> //xaRes.commit(xid, false);
> System.out.println("MESSAGE SORT OF COMMITTED [" +
> message.getJMSMessageID() + "]");
> } {code}
>
> After this the message seems to be stuck on the queue because it is still
> being delivered to a consumer which is already gone. They show up in the
> queue metrics but the actual message/content cannot be seen, queried,
> consumed etc. We can see them using "artemis data exp" however.
>
> We have the following questions:
> 1) Is there a way to get these messages out of this state, i..e. route them
> to an expiry-queue after 24 hours or manualy ?
> 2) Is there (apart from "artemis data exp") a way to see the content ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
