Chapter 6. Known Issues

ENTMQBR-17 - AMQ222117: Unable to start cluster connection

A broker cluster may fail to initialize properly in environments that support IPv6. The failure is due to a SocketException that is indicated by the log message Can’t assign requested address. To work around this issue, set the java.net.preferIPv4Stack system property to true.

ENTMQBR-463 - Attributes in clustering settings have order restrictions. Would be nice to either have better error message or simply ignore the order

Currently the sequence of the elements in the cluster connection configuration has to be in a specific order. The workaround is to adhere to the order in the configuration schema.

ENTMQBR-520 - Receiving from address named the same as a queue bound to another address should not be allowed

A queue with the same name as an address must only be assigned to address. Creating a queue with the same name as an existing address, but bound to an address with a different name, is an invalid configuration. Doing so can result in incorrect messages being routed to the queue.

ENTMQBR-522 - Broker running on windows write problems with remove temp files when shutting down

On Windows, the broker does not successfully clean up temporary files when it shuts down. This issue causes the shutdown process to be slow. In addition, temporary files not deleted by the broker accumulate over time.

ENTMQBR-569 - Conversion of IDs from OpenWire to AMQP results in sending IDs as binary

When communicating cross-protocol from an A-MQ 6 OpenWire client to an AMQP client, additional information is encoded in the application message properties. This is benign information used internally by the broker and can be ignored.

ENTMQBR-599 - Define truststore and keystore by Artemis cli

Creating a broker instance by using the --ssl-key, --ssl-key-password, --ssl-trust, and --ssl-trust-password parameters does not work. To work around this issue, set the corresponding properties manually in bootstrap.xml after creating the broker.

ENTMQBR-617 - Cert based authentication does not work with AMQP and OpenWire clients

Authentication based on SSL certificates is not supported for AMQP and OpenWire clients.

ENTMQBR-636 - Journal breaks, causing JavaNullPointerException, under perf load (mpt)

To prevent IO-related issues from occurring when the broker is managing heavy loads, verify that the JVM is allocated with enough memory and heap space. See the section titled "Tuning the VM" in the Performance Tuning chapter of the ActiveMQ Artemis documentation.

ENTMQBR-648 - JMS Openwire client is unable to send messages to queue with defined purgeOnNoConsumer or queue filter

Using an A-MQ 6 JMS client to send messages to an address that has a queue with purgeOnNoConsumer set to true fails if the queue has no consumers. It is recommended that you do not set the purgeOnNoConsumer option when using A-MQ 6 JMS clients.

ENTMQBR-652 - List of known amq-jon-plugin bugs

This version of amq-jon-plugin has known issues with the MBeans for broker and queue.

Issues with the broker MBean:

Issues with the queue MBean:

ENTMQBR-655 - [AMQP] Unable to send message when populate-validated-user is enabled

The configuration option populate-validated-user is not supported for messages produced using the AMQP protocol.

ENTMQBR-738 - Unable to build AMQ 7 examples offline with provided offline repo

You cannot build the examples included with AMQ Broker in an offline environment. This issue is caused by missing dependencies in the provided offline Maven repository.

ENTMQBR-897 - Openwire client/protocol issues with special characters in destination name

Currently AMQ OpenWire JMS clients cannot access queues and addresses that include the following characters in their name: comma (','), hash ('#'), greater than ('>'), and whitespace.

ENTMQBR-944 - [A-MQ7, Hawtio, RBAC] User gets no feedback if operation access was denied by RBAC

The console can indicate that an operation attempted by an unauthorized user was successful when it was not.

ENTMQBR-1498 - Diagram in management console for HA (replication, sharedstore) does not reflect real topology

If you configure a broker cluster with some extra, passive slaves, the cluster diagram in the web console does not show these passive slaves.

ENTMQBR-1815 - Hawtio view changes on automated refresh

When automatic refresh is enabled, the Hawtio console updates the screen every 5 seconds. Automatic refreshes also change the view to the Attributes screen, causing you to lose focus from any other screen you are viewing. To work around this issue, select Preferences in the top-right corner of the console. In the Update rate drop-down list, select No refreshes.

ENTMQBR-1848 - "javax.jms.JMSException: Incorrect Routing Type for queue, expecting: ANYCAST" occurs when qpid-jms client consumes a message from a multicast queue as javax.jms.Queue object with FQQN

Currently, sending a message by using the Qpid JMS client to a multicast queue by using FQQN (fully qualified queue name) to an address that has multiple queues configured generates an error message on the client, and the message cannot be sent. To work around this issue, modify the broker configuration to resolve the error and unblock the client.

ENTMQBR-1875 - [AMQ 7, ha, replicated store] backup broker appear not to go "live" or shutdown after - ActiveMQIllegalStateException errorType=ILLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live

Removing the paging disk of a master broker while a backup broker is trying to sync with the master broker causes the master to fail. In addition, the backup broker cannot become live because it continues trying to sync with the master.

ENTMQBR-1942 - [AMQ 7.2, shared store, scale down] NullPointer exception when slave activates and tries to scale down

If you configure a slave broker to use a shared store and scaledown in a cluster, you can encounter an exception on the slave if the master broker goes offline.

ENTMQBR-2068 - some messages received but not delivered during HA fail-over, fail-back scenario

Currently, if a broker fails over to its slave while an OpenWire client is sending messages, messages being delivered to the broker when failover occurs could be lost. To work around this issue, ensure that the broker persists the messages before acknowledging them.

ENTMQBR-2452 - Upgraded broker AMQ 7.3.0 from AMQ 7.2.4 on Windows cannot log

If you intend to upgrade a broker instance from 7.2.4 to 7.3.0 on Windows, logging will not work unless you specify the correct log manager version during your upgrade process. For more information, see Upgrading from 7.2.x to 7.3.0 on Windows.

ENTMQBR-2470 - [AMQ7, openwire,redelivery] redelivery counter for message increasing, if consumer is closed without consuming any messages

If a broker sends a message to an Openwire consumer, but the consumer is closed before consuming the message, the broker wrongly increments the redelivery count for the pending message. If the number of occurrences of this behavior exceeds the value of the max-delivery-attempts configuration parameter, the broker sends the message to the dead letter queue (DLQ) or drops the message, based on your configuration. This issue does not affect other protocols, such as the Core protocol.

ENTMQBR-2593 - broker does not set message ID header on cross protocol consumption

A Qpid JMS client successfully retrieves a message ID only if the message was produced by another Qpid JMS client. If the message was produced by a Core JMS or OpenWire client, the Qpid JMS client cannot read the message ID.

ENTMQBR-2678 - After isolated master is live again it is unable to connect to the cluster

In a cluster of three or more live-backup groups that is using the replication high availability (HA) policy, the live broker shuts down when its replication connection fails. However, when the replication connection is restored and the original live broker is restarted, the broker is sometimes unable to rejoin the broker cluster. To enable the original live broker to rejoin the cluster, first stop the new live (original backup) broker, restart the original live broker, and then restart the original backup broker.

ENTMQBR-2711 - ServerSessionImpl cache does not clear names of deleted temporary destinations

When you create and delete temporary queues, the broker does not remove these queue names from the internal ServerSessionImpl cache. Over time, this data accumulates, causing a memory leak.

ENTMQBR-2767 - [AMQ7, purge message, OutOfMemoryException] with a large queue size, removeAllMessages() takes a long time and can eventually result in an OOM exception

For a queue with a large number (that is, in the order of millions) of messages, the JMX operation removeAllMessages can take up to several minutes to complete. In addition, the operation sometimes fails to complete, returning an out-of-memory (OOM) exception instead.

ENTMQBR-2890 - Infrequently, creating a CR instance with size n > 1 causes the the nth broker pod to start and immediately restart once

If you use a Custom Resource (CR) instance to deploy a broker cluster via the AMQ Broker Operator, the final broker Pod in the deployment (as determined by the size attribute of your CR) starts and then immediately restarts one time before it is usable. To work around this issue, incrementally increase the size attribute of your CR to reach the desired cluster size. First, set size to 1 and wait for the broker Pod to start. Then, set size to 2, wait for the Pod to start, and so on. In this case, none of the broker Pods undergo a restart before they are usable.

ENTMQBR-2942 - Pod #0 tries to contact non-existent Pods

If you change the size attribute of your Custom Resource (CR) instance to scale down a broker deployment, the first broker Pod in the cluster can make repeated attempts to connect to the drainer Pods that started up to migrate messages from the brokers that shut down, before they shut down themselves. To work around this issue, follow these steps:

1) Scale your deployment to a single broker Pod.

2) Wait for all drainer Pods to start, complete message migration, and then shut down.

3) If the single remaining broker Pod has log entries for an “unknown host exception”, scale the deployment down to zero broker Pods, and then back to one.

4) When you have verified that the single remaining broker Pod is not recording exception-based log entries, scale your deployment back to its original size.