kubernetes - Kubernetes での JMS 2.0 永続サブスクリプション トピックのベスト プラクティス

Question

Kubernetes のコンテナで実行され、JMS 2.0 Red Hat AMQ 7 (ActiveMQ Artemis に基づく) に接続されるレプリカ セットに含まれる Mule アプリケーションを作成しています。

pom.xml は、jms クライアントを取得するように構成されています。

<dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>artemis-jms-client-all</artifactId>
  <version>2.10.1</version>
</dependency>

また、JMS 構成は次のように構成されます。

<jms:config name="JMS_Config" doc:name="JMS Config" doc:id="8621b07d-b203-463e-bbbe-76eb03741a61" >
    <jms:generic-connection specification="JMS_2_0" username="${mq.user}" password="${mq.password}" clientId="${mq.client.id}">
        <reconnection >
            <reconnect-forever frequency="${mq.reconnection.frequency}" />
        </reconnection>
        <jms:connection-factory >
            <jms:jndi-connection-factory connectionFactoryJndiName="ConnectionFactory" >
                <jms:name-resolver-builder jndiInitialContextFactory="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory" jndiProviderUrl="${mq.brokerurl}"/>
            </jms:jndi-connection-factory>
        </jms:connection-factory>
    </jms:generic-connection>
    <jms:consumer-config>
        <jms:consumer-type >
            <jms:topic-consumer shared="true" durable="true"/>
        </jms:consumer-type>
    </jms:consumer-config>
    <jms:producer-config persistentDelivery="true"/>
</jms:config>

次に、JMS リスナー コンポーネントで次のようにします。

<jms:listener doc:name="EMS JMS Listener" doc:id="318b4f08-daf6-41f4-944b-3ec1420d5c12" config-ref="JMS_Config" destination="${mq.incoming.queue}" ackMode="AUTO" >
    <jms:consumer-type >
        <jms:topic-consumer shared="true" subscriptionName="${mq.sub.name}" durable="true"/>
    </jms:consumer-type>
    <jms:response sendCorrelationId="ALWAYS" />
</jms:listener>

変数は次のように設定されます。

mq.client.id=client-id-135a9514-d4d5-4f52-b01c-f6ca34a76b40
mq.sub.name=my-sub
mq.incoming.queue=my-queue

これは、クライアントを構成するための最良の方法ですか? AMQ サーバーへの接続に関して、K8s にデプロイされたときにログにエラーが表示されたように:

javax.jms.InvalidClientIDException: client-id-135a9514-d4d5-4f52-b01c-f6ca34a76b40 was already set into another connection