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
SocketExceptionthat is indicated by the log message
Can’t assign requested address. To work around this issue, set the
java.net.preferIPv4Stacksystem property to
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-trust-passwordparameters does not work. To work around this issue, set the corresponding properties manually in
bootstrap.xmlafter 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
Using an A-MQ 6 JMS client to send messages to an address that has a queue with
truefails if the queue has no consumers. It is recommended that you do not set the
purgeOnNoConsumeroption when using A-MQ 6 JMS clients.
ENTMQBR-652 - List of known
This version of
amq-jon-pluginhas known issues with the MBeans for broker and queue.
Issues with the broker MBean:
Closing a connection throws
Adding address settings throws
getConnectorServices()operation cannot be found
listConsumersAsJSON()operation cannot be found
getDivertNames()operation cannot be found
Listing network topology throws
- Remove address settings has wrong parameter name
Issues with the queue MBean:
expireMessage()throws argument type mismatch exception
IllegalArgumentExceptionwith error message argument type mismatch
IllegalArgumentExceptionwith error message argument type mismatch
removeMessages()throws exception with error Can’t find operation removeMessage with 2 arguments
retryMessage()throws argument type mismatch
- Closing a connection throws
ENTMQBR-655 - [AMQP] Unable to send message when
The configuration option
populate-validated-useris 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
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.Queueobject 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-attemptsconfiguration 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
ServerSessionImplcache. 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
removeAllMessagescan 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
sizeattribute of your CR) starts and then immediately restarts one time before it is usable. To work around this issue, incrementally increase the
sizeattribute of your CR to reach the desired cluster size. First, set
1and wait for the broker Pod to start. Then, set
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
sizeattribute 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.