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_ARGS list in the artemis.profile file.
    • 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.
  • 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 the JAVA_ARGS list of Java system arguments in the artemis.profile file. 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.ingressDomain attribute 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 the spec.host field 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 ActiveMQArtemis CR:

    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 scope

    The 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 messageMigration attribute in a running broker deployment. To work around this issue, you must set the required value for the messageMigration attribute in a new ActiveMQ Artemis CR 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 adminUser and adminPassword attributes 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 the adminUser and adminPassword attributes 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 the adminUser and adminPassword attributes 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.size property of a Custom Resource (CR) instance to specify an initial size for the PVC. If you modify the CR to specify a different value of storage.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 PVC and enter a new value.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red Hat
Volver arriba