[
https://issues.apache.org/jira/browse/ARTEMIS-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428347#comment-17428347
]
Justin Bertram edited comment on ARTEMIS-3526 at 10/13/21, 5:08 PM:
--------------------------------------------------------------------
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. All the messages which were part of the transaction are
therefore not available to any other client.
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}}.
This kind of situation is also discussed briefly in [the
documentation|https://activemq.apache.org/components/artemis/documentation/latest/transaction-config.html].
was (Author: jbertram):
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. All the messages which were part of the transaction are
therefore not available to any other client.
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)
