[
https://issues.apache.org/jira/browse/ARTEMIS-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006849#comment-17006849
]
miroch commented on ARTEMIS-2583:
---------------------------------
Yes, after the XA-transaction times out, the message "returns" to the queue and
is ready for delivery again. Thus the message is not in the "delivering" state
permanently, but only until the transaction times out and one does not need to
restart the Artemis MQ server, but only wait until the XA-transaction times
out. Therefore, this comment makes things much better. However, it does not
solve the problem fully, because the following questions remain:
* Why there is a difference in behavior relative to the source of the original
message? If the message is originally created by the WebConsole, we have to
wait for transaction timeout after the XA-reader crashes to normalize the
message state, but if the message is originally created by the attached program
ArtemisXASender. no waiting for transaction timeout is necessary: the message
state normalizes immediately after the XA-reader crashes.
* While the message is in the "delivering" state (that is after the XA-reader
crashed but before the XA transaction times out), the server responses are
suspicious: the method *countDeliveringMessages()* for the queue exampleQueue
in WebConsole returns 1 but the method *listDeliveringMessages()* for the queue
exampleQueue in WebConsole returns an empty list. This seems to be inconsistent.
> Message permanently in "delivering" state if a JMS XA client crashes
> --------------------------------------------------------------------
>
> Key: ARTEMIS-2583
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2583
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Web Console
> Affects Versions: 2.10.1
> Environment: Windows 10
> Reporter: miroch
> Priority: Critical
> Attachments: ArtemisXaReceiveCrashTest.java, ArtemisXaSender.java,
> pom.xml
>
>
> h2. Symptoms:
> If a message is created and sent to a queue using the *ArtemisMQ Web console*
> and then read by the JMS XA client program, but the client crashes before it
> completes its XA transaction, the ArtemisMQ server correctly recognizes that
> the client has died. However, the message does not "return" to the queue.
> Instead, it remains "delivering" permanently and thus it is not accessible
> anymore (until ArtemisMQ server is restarted: the things normalize
> afterwards).
> h2. Steps to reproduce:
> 1. Note that due to a nature of this bug it is not possible to demonstrate it
> in an embedded environment. A separate instance of Artemis MQ is needed
> instead. Therefore install the ArtemisMQ 2.10.1
> (https://www.apache.org/dyn/closer.cgi?filename=activemq/activemq-artemis/2.10.1/apache-artemis-2.10.1-bin.zip&action=download)
> and use its out-of-the-box configuration with only a single change: add the
> address for exampleQueue into broker.xml, so that the queue is permanently
> visible in the WebConsole:
> {{<address name="exampleQueue">}}
> {{ <anycast>}}
> {{ <queue name="exampleQueue" />}}
> {{ </anycast>}}
> {{</address>}}
> 2. Access the WebConsole and navigate to exampleQueue. Then send a durable
> plain text message *via WebConsole (this is important)* into this queue.
> 3. Setup the XA client. The attached source-code is based on the example
> "xa-recieve" from
> https://github.com/apache/activemq-artemis/tree/master/examples/features/standard/xa-receive
> The client code is located in ArtemisXaReceiveCrashTest. In order to get it
> running, add DummyXid and jndi.properties from
> https://github.com/apache/activemq-artemis/blob/master/examples/features/standard/xa-receive/src/main/java/org/apache/activemq/artemis/jms/example/DummyXid.java
> and
> https://github.com/apache/activemq-artemis/blob/master/examples/features/standard/xa-receive/src/main/resources/jndi.properties,
> respectively. The only library needed is artemis-jms-client-all (version
> 2.10.1): see the attached pom.xml
> 4. Run the main method of ArtemisXaReceiveCrashTest. It reads the message out
> of exampleQueue within an XA-transaction, however, it terminates the Java VM
> before rolling-back or committing the transaction.
> 5. If you now execute the method "browse()" for the queue exampleQueue via
> WebConsole, it returns an empty list. If you execute the method
> listDeliveringMessages() for the queue exampleQueue via WebConsole, it
> returns an empty list. If you execute the method countDeliveringMessages()
> for the queue exampleQueue via WebConsole, it returns 1. This state is
> permanent: the message does not reappear back in the queue. The situation
> normalizes after the ArtemisMQ server is restarted: the message is then again
> available for delivery.
> h2. Variations:
> * The situation does not improve, if the JMS XA client closes the connection
> and session properly and terminates without rolling-back or committing the
> transaction. The behaviour is the same. This can be simulated, if the line
> containing "System.exit(0)" in ArtemisXaReceiveCrashTest is commented out.
> * On the other hand, if the message is created and sent programmatically
> using the attached program ArtemisXaSender (again based on an ArtemisMQ
> example "xa-receive") instead of the WebConsole, the server behaviour is
> correct: after the reading XA client crashes, the message correctly appears
> back in the exampleQueue. Therefore it seems that the problem is somehow
> related to the way the WebConsole sends and/or formats the message.
> * If the reading client is transacted, but no XA-client, there is no
> problem, even if the message is sent via WebConsole.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
