Chapter 8. Known issues

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:

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 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.