Ensuring proper JMS message group routing in clustered setup

[stevepentland]

I'm having a bit of an issue after using a deployment with the following deploymentPlan:

  deploymentPlan:
    size: 3
    persistenceEnabled: true
    messageMigration: true
    enableMetricsPlugin: true
    podSecurityContext:
      fsGroup: 0
    resources:
      limits:
        cpu: "500m"
        memory: "2Gi"
      requests:
        cpu: "250m"
        memory: "512Mi"

My issue now is that we make use of message grouping in JMS to obtain the behaviour we need for a number of very critical queues. This is also not something we can easily change.

When reading the Artemis documentation around grouping, the section on Clustered Grouping (https://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html#clustered-grouping-configuration) outlines the exact issue we now seem to be experiencing.

After confirming there were no instances of grouping-handler entries in broker.xml on the pods, I started looking through the CRDs for a way to ensure grouping-handler entries were created for all broker pods in the StatefulSet. However I have so far been unable to find any way to make sure these are added to my artemis cluster.

I did find the defaultGroup* keys in the broker & address CRDs, though these do not seem to be related to the grouping-handler entries I am looking to generate into broker.xml. I would be very grateful if someone could point me to the method I need to use to ensure our JMS grouped messages are properly routed through our cluster.

Thanks so much in advance for any advice, and also thanks to the community for making Artemis and AMQ in general much more accessible to deploy in high volume clustered environments!

[gtully]

I think you will need to make use of a connection router to partition your clients and confine clients that wish to respect groups on a given queue to a single broker. Once a queue is distributed, message order and consequently group order, is lost (compromised).

There is an example of this sort of sharding based on roles in the pub sub test, the context there is avoiding duplicates for topic consuemrs, but it can be applied to partition order sensitive queue consumers in a similar way. see : https://github.com/artemiscloud/activemq-artemis-operator/blob/main/controllers/activemqartemis_pub_sub_scale_test.go#L193

[g-hodgson-tup]

I too was looking to configure grouping-handler in the ActiveMQArtemis CR. I believe that this configuration makes it possible: https://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html#clustered-grouping-example

For example, I have confgured the following

apiVersion: broker.amq.io/v1beta1
kind: ActiveMQArtemis
metadata:
  name: artemis-broker
spec:
  ...
  brokerProperties:
    - addressConfigurations.demoQueue.routingTypes=ANYCAST
    - addressConfigurations.demoQueue.queueConfigs.demoQueue.address=demoQueue
    - addressConfigurations.demoQueue.queueConfigs.demoQueue.routingType=ANYCAST
    - broker-0.groupingHandlerConfiguration.name=my-grouping-handler
    - broker-0.groupingHandlerConfiguration.type=LOCAL
    - broker-0.groupingHandlerConfiguration.address=demoQueue
    - broker-0.groupingHandlerConfiguration.timeout=5000
    - broker-1.groupingHandlerConfiguration.name=my-grouping-handler
    - broker-1.groupingHandlerConfiguration.type=REMOTE
    - broker-1.groupingHandlerConfiguration.address=demoQueue
    - broker-1.groupingHandlerConfiguration.timeout=5000

and have been able to successfully route messages accordingly.