Chapter 7. Known issues
This section describes known issues in AMQ Broker 7.9.
ENTMQBR-5749 - Remove unsupported operators that are visible in OperatorHub
Only the Operators and Operator channels mentioned in Deploying the Operator from OperatorHub are supported. For technical reasons associated with Operator publication, other Operator and channels are visible in the OperatorHub and should be ignored. For reference, the following list shows which Operators are visble, but not supported:
- Red Hat Integration - AMQ Broker LTS - all channels
- Red Hat Integration - AMQ Broker - alpha, current, and current-76
ENTMQBR-5615 - Unexpected breaking change in artemis.profile prevents "init container image" approach
If you use the JVM option
-Dhawtio.roleto set user roles as part of the $JAVA_ARGS section of theartemis_profilefile, users might not be able to access the broker console.This issue is caused by a new property
HAWTIO_ROLEwhich overrides any values set by-Dhawtio.role. To workaround this problem, set the appropriate roles using theHAWTIO_ROLEproperty in theetc/artemis.profilefile.
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 messageCan’t assign requested address. To work around this issue, set thejava.net.preferIPv4Stacksystem property totrue.
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-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-passwordparameters does not work. To work around this issue, set the corresponding properties manually inbootstrap.xmlafter creating the broker.
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
purgeOnNoConsumeror queuefilterUsing an A-MQ 6 JMS client to send messages to an address that has a queue with
purgeOnNoConsumerset totruefails if the queue has no consumers. It is recommended that you do not set thepurgeOnNoConsumeroption when using A-MQ 6 JMS clients.
ENTMQBR-652 - List of known
amq-jon-pluginbugsThis version of
amq-jon-pluginhas known issues with the MBeans for broker and queue.Issues with the broker MBean:
-
Closing a connection throws
java.net.SocketTimeoutExceptionexception -
listSessions()throwsjava.lang.ClassCastException -
Adding address settings throws
java.lang.IllegalArgumentException -
getConnectorServices()operation cannot be found -
listConsumersAsJSON()operation cannot be found -
getDivertNames()operation cannot be found -
Listing network topology throws
IllegalArgumentException - Remove address settings has wrong parameter name
Issues with the queue MBean:
-
expireMessage()throws argument type mismatch exception -
listDeliveringMessages()throwsIllegalArgumentException -
listMessages()throwsjava.lang.Exception -
moveMessages()throwsIllegalArgumentExceptionwith error message argument type mismatch -
removeMessage()throwsIllegalArgumentExceptionwith error message argument type mismatch -
removeMessages()throws exception with error Can’t find operation removeMessage with 2 arguments -
retryMessage()throws argument type mismatchIllegalArgumentException
-
Closing a connection throws
ENTMQBR-655 - [AMQP] Unable to send message when
populate-validated-useris enabledThe configuration option
populate-validated-useris not supported for messages produced using the AMQP protocol.
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-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-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-2928 - Broker Operator unable to recover from CR changes causing erroneous state
If the AMQ Broker Operator encounters an error when applying a Custom Resource (CR) update, the Operator does not recover. Specifically, the Operator stops responding as expected to further updates to your CRs.
For example, say that a misspelling in the value of the
imageattribute in your main broker CR causes broker Pods to fail to deploy, with an associated error message ofImagePullBackOff. If you then fix the misspelling and apply the CR changes, the Operator does not deploy the specified number of broker Pods. In addition, the Operator does not respond to any further CR changes.To work around this issue, you must delete the CRs that you originally deployed, before redeploying them. To delete an existing CR, use a command such as
oc delete -f <CR name>.
ENTMQBR-3846 - MQTT client does not reconnect on broker restart
When you restart a broker, or a broker fails over, the active broker does not restore connections for previously-connected MQTT clients. To work around this issue, to reconnect an MQTT client, you need to manually call the
subscribe()method on the client.
ENTMQBR-4023 - AMQ Broker Operator: Pod Status pod names do not reflect the reality
For an Operator-based broker deployment in a given OpenShift project, if you use the
oc get podcommand to list the broker Pods, the ordinal values for the Pods start at0, for example,amq-operator-test-broker-ss-0. However, if you use theoc describecommand to get the status of broker Pods created from theactivemqartmisesCustom Resource (that is,oc describe activemqartemises), the Pod ordinal values incorrectly start at1, for example,amq-operator-test-broker-ss-1. There is no way to work around this issue.
ENTMQBR-4127 - AMQ Broker Operator: Route name generated by Operator might be too long for OpenShift
For each broker Pod in an Operator-based deployment, the default name of the Route that the Operator creates for access to the AMQ Broker management console includes the name of the Custom Resource (CR) instance, the name of the OpenShift project, and the name of the OpenShift cluster. For example,
my-broker-deployment-wconsj-0-svc-rte-my-openshift-project.my-openshift-domain. If some of these names are long, the default Route name might exceed the limit of 63 characters that OpenShift enforces. In this case, in the OpenShift Container Platform web console, the Route shows a status ofRejected.To work around this issue, use the OpenShift Container Platform web console to manually edit the name of the Route. In the console, click the Route. On the Actions drop-down menu in the top-right corner, select
Edit Route. In the YAML editor, find thespec.hostproperty and edit the value.
ENTMQBR-4140 - AMQ Broker Operator: Installation becomes unusable if
storage.sizeis improperly specifiedIf you configure the
storage.sizeproperty of a Custom Resource (CR) instance to specify the size of the Persistent Volume Claim (PVC) required by brokers in a deployment for persistent storage, the Operator installation becomes unusable if you do not specify this value properly. For example, suppose that you set the value ofstorage.sizeto1(that is, without specifying a unit). In this case, the Operator cannot use the CR to create a broker deployment. In addition, even if you remove the CR and deploy a new version withstorage.sizespecified correctly, the Operator still cannot use this CR to create a deployment as expected.To work around this issue, first stop the Operator. In the OpenShift Container Platform web console, click Deployments. For the Pod that corresponds to the AMQ Broker Operator, click the More options menu (three vertical dots). Click Edit Pod Count and set the value to
0. When the Operator Pod has stopped, create a new version of the CR withstorage.sizecorrectly specified. Then, to restart the Operator, click Edit Pod Count again and set the value back to1.
ENTMQBR-4141 - AMQ Broker Operator: Increasing Persistent Volume size requires manual involvement even after recreating Stateful Set
If you try to increase the size of the Persistent Volume Claim (PVC) required by brokers in a deployment for persistent storage, the change does not take effect without further manual steps. For example, suppose that you configure the
storage.sizeproperty of a Custom Resource (CR) instance to specify an initial size for the PVC. If you modify the CR to specify a different value ofstorage.size, the existing brokers continue to use the original PVC size. This is the case even if you scale the deployment down to zero brokers and then back up to the original number. However, if you scale the size of the deployment up to add additional brokers, the new brokers use the new PVC size.To work around this issue, and ensure that all brokers in the deployment use the same PVC size, use the OpenShift Container Platform web console to expand the PVC size used by the deployment. In the console, click Storage → Persistent Volume Claims. Click your deployment. On the Actions drop-down menu in the top-right corner, select
Expand PVCand enter a new value.