[
https://issues.apache.org/jira/browse/ARTEMIS-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008030#comment-17008030
]
Justin Bertram edited comment on ARTEMIS-2583 at 1/6/20 7:05 PM:
-----------------------------------------------------------------
I planned to check behaviour of version 2.11.0-SNAPSHOT. Unfortunately, current
snapshot of apache-artemis
([https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-artemis/2.11.0-SNAPSHOT/apache-artemis-2.11.0-20200103.031337-51-bin.zip)]
fails to start out-of-the-box (it reports "Failure in initialisation:
java.io.IOException: The process cannot access the file because another process
has locked a portion of the file"). Of course, this does not relate to
ARTEMIS-2583, but it prevents me from checking. Here is the full stack-trace:
{noformat}
2020-01-04 21:36:10,726 ERROR [org.apache.activemq.artemis.core.server]
AMQ224000: Failure in initialisation: java.io.IOException: The process cannot
access the file because another process has locked a portion of the file
at sun.nio.ch.FileDispatcherImpl.pwrite0(Native Method) [rt.jar:1.8.0_25]
at sun.nio.ch.FileDispatcherImpl.pwrite(Unknown Source) [rt.jar:1.8.0_25]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(Unknown Source) [rt.jar:1.8.0_25]
at sun.nio.ch.IOUtil.write(Unknown Source) [rt.jar:1.8.0_25]
at sun.nio.ch.FileChannelImpl.writeInternal(Unknown Source) [rt.jar:1.8.0_25]
at sun.nio.ch.FileChannelImpl.write(Unknown Source) [rt.jar:1.8.0_25]
at
org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.writeFileLockStatus(FileLockNodeManager.java:307)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.setFailingBack(FileLockNodeManager.java:283)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.startLiveNode(FileLockNodeManager.java:230)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:70)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:600)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:527)
[artemis-server-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at
org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:70)
[artemis-cli-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:84)
[artemis-cli-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:150)
[artemis-cli-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:98)
[artemis-cli-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:125)
[artemis-cli-2.11.0-SNAPSHOT.jar:2.11.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
[rt.jar:1.8.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
[rt.jar:1.8.0_25]
at java.lang.reflect.Method.invoke(Unknown Source) [rt.jar:1.8.0_25]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
[artemis-boot.jar:2.11.0-SNAPSHOT]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)
[artemis-boot.jar:2.11.0-SNAPSHOT]{noformat}
was (Author: mc399777):
I planned to check behaviour of version 2.11.0-SNAPSHOT. Unfortunately, current
snapshot of apache-artemis
([https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-artemis/2.11.0-SNAPSHOT/apache-artemis-2.11.0-20200103.031337-51-bin.zip)]
fails to start out-of-the-box (it reports "Failure in initialisation:
java.io.IOException: The process cannot access the file because another process
has locked a portion of the file"). Of course, this does not relate to
ARTEMIS-2583, but it prevents me from checking.
> 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)
