The single commit here is much easier to understand so thanks for that.
However, I don't believe technical solution is viable as it relies on the address for the subscription matching the address in the cluster-connection which would likely only happen if it was specifically configured that way which would preclude other clustered addresses.
I think the real solution would be to address why the message-load-balancing-type isn't being set on the subscription queues in the first place.
For what I have analysed in the artemis code, the message-load-balancing-type is only set for queues configured in the broker.xml.
When you publish to an auto created queue it seems the load balancing type isn't set by the postoffice.
So can you help me understand how this is supposed to work in order to fix it? I can do this without using the address and using the value defined in the default cluster connection. What do you think?
> For what I have analysed in the artemis code, the message-load-balancing-type is only set for queues configured in the broker.xml.
I don't believe that's true. If you change your example to create subscriptions on "test/1/some/la" instead of "test/+/some/#" and also remove the <addresses> block from the broker.xml files then the address "test/1/some/la" will be created along with the corresponding subscription queues automatically when the client runs. In this situation I can see that the messages are load-balanced properly among the cluster nodes. This leads me to believe that the issue is with how the subscription queues with wildcards (i.e. "test/+/some/#") are interacting with the messages send to a specific address (i.e. "test/1/some/la").
It would be ideal to have a real test in the test-suite to validate this functionality instead of just an example. I think that once a test was created you could get rid of the example completely. If you wanted to keep the example after the test was created I would move it to the protocols/mqtt section rather than the features/clustered section.