Este contenido no está disponible en el idioma seleccionado.
Chapter 8. Known issues
This section describes known issues in AMQ Broker 7.13.
ENTMQBR-10309 - RBAC is not applied for the tabs (browse message and send message) for the queue elements in the Artemis JMX tree
In the Artemis JMX tree of the AMQ Management Console, the tabs displayed for queue elements do not reflect a user’s address permissions. All tabs appear for a queue regardless of the permissions granted to the user. To work around this issue, set the following Java system property:
-Djolokia.disabledServices=org.jolokia.integration.artemis.ArtemisCacheKeyProvider-
On AMQ Broker on RHEL, add the JAVA system property to the
JAVA_ARGSlist in theartemis.profilefile. - On AMQ Broker on OpenShift, set the JAVA system property in an environment variable. For more information about setting environment variables, see Setting environment variables for the broker containers in Deploying AMQ Broker on OpenShift.
-
On AMQ Broker on RHEL, add the JAVA system property to the
ENTMQBR-9810 - Using Java23 results in UnsupportedOperationException: getSubject is supported only if a security manager is allowed
When you use AMQ Broker 7.13 with Java 23, the following error is displayed:
java.lang.UnsupportedOperationException: getSubject is supported only if a security manager is allowed at java.base/javax.security.auth.Subject.getSubject(Subject.java:347) at …..To resolve this issue, add a new argument,
-Djava.security.manager=allow, to theJAVA_ARGSlist of Java system arguments in theartemis.profilefile. This argument enables support for a security manager without actually using one.
ENTMQBR-9791 - Failed startup of console when install dir has unicode characters.
If you rename the default directory, created when you extracted the broker installation archive, to a directory name that contains unicode characters, the AMQ Management Console is unable to start. The following error is displayed in the logging information shown when you start the broker:
WARN [org.eclipse.jetty.ee9.webapp.WebAppContext] Failed startup of context oeje9w.WebAppContext@626d2016{/metrics,/metrics,null,false,@Connector-0}{/home/jcliffor/Downloads/<directory name>/web/metrics.war}__ java.lang.IllegalArgumentException: Bad escape
ENTMQBR-9109 - Changing ingressDomain doesn’t update Routes.
If you change the value of the
spec.ingressDomainattribute to an empty value, the domain value is not updated in existing routes. This issue is due to a limitation of the OpenShift routes whereby thespec.hostfield of the OpenShift routes is auto-generated if it is empty only when a new route is created.
ENTMQBR-9187 - The Operator shows forbidden errors when you deploy a CR and message migration does not work as expected.
If you install the Operator by using the OpenShift CLI or using OperatorHub with custom YAML files, you can configure the Operator to watch multiple namespaces or a single namespace that is different from the one in which the Operator is installed. In both of these configurations, the following error is displayed when you deploy the
ActiveMQArtemisCR:W0614 14:18:59.355936 1 reflector.go:535] k8s.io/client-go/informers/factory.go:150: failed to list *v1.StatefulSet: statefulSets.apps is forbidden: User "system:serviceaccount:amq-broker-operator-olm:amq-broker-controller-manager" cannot list resource "statefulSets" in API group "apps" at the cluster scopeThe broker deployment is created and works as normal. However, if you scale down the deployment subsequently, messages on the broker that was removed are not migrated to another broker and are lost.
To avoid this issue, allow the Operator to watch all namespaces, which is the default, or configure the Operator to watch the single namespace in which the Operator is installed.
ENTMQBR-8106 - AMQ Broker Drainer pod doesn’t function properly after changing MessageMigration in CR
You cannot change the value of the
messageMigrationattribute in a running broker deployment. To work around this issue, you must set the required value for themessageMigrationattribute in a newActiveMQ ArtemisCR and create a new broker deployment.
ENTMQBR-7359 - Change to current handling of credential secret with 7.10.0 Operator
The Operator stores the administrator username and password for connecting to the broker in a secret. The default secret name is in the form
<custom-resource-name>-credentials-secret. You can create a secret manually or allow the Operator to create a secret.If the
adminUserandadminPasswordattributes are configured in a Custom Resource before 7.10.0, the Operator updates a manually-created secret with the values of these attributes. Starting in 7.10.0, the Operator no longer updates a secret that was created manually. Therefore, if you change the values of theadminUserandadminPasswordattributes in the CR, you must either: f * Update the secret with the new username and password * Delete the secret and allow the Operator to create a secret. When the Operator creates a secret, it adds the values of theadminUserandadminPasswordattributes if these are specified in the CR. If these attributes are not in the CR, the Operator generates random credentials for the secret.
ENTMQBR-7111 - 7.10 versions of operator tend to remove StatefulSet during upgrade
If you are upgrading to or from AMQ Broker Operator 7.10.0, the new Operator automatically deletes the existing StatefulSet for each deployment during the reconciliation process. When the Operator deletes the StatefulSet, the existing broker pods are deleted, which causes a temporary broker outage.
You can work around this issue by running the following command to manually delete the StatefulSet and orphan the running pods before the Operator gets to delete the StatefulSet: oc delete statefulSet <statefulSet-name> --cascade=orphan
Manually deleting the StatefulSet during the upgrade process allows the new Operator to reconcile the StatefulSet without deleting the running pods. For more information, see Upgrading the Operator using OperatorHub in Deploying AMQ Broker on OpenShift.
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 visible, but not supported:
- Red Hat Integration - AMQ Broker LTS - all channels
- Red Hat Integration - AMQ Broker - alpha, current, and current-76
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 menu:Storage[Persistent Volume Claims]. Click your deployment. On the Actions drop-down menu in the upper-right corner, select
Expand PVCand enter a new value.