[jira] [Comment Edited] (ARTEMIS-3526) Messages get stuck in delivering status on a queue.

["Justin Bertram (Jira)" <ji...@apache.org>]

    [ 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:03 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}}.


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. 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)