I was expecting Message 2 to be consume by Broker 1, because both message
are in the same broker using the same group. My next test will be tests this
sending Message 2 to Broker 2 directly, but this very use case seems broken.
If you're going to be using message grouping in a cluster then you'll
definitely want to configure it properly (i.e. according to the
documentation you cited). That said, message grouping imposes a natural
penalty on performance due to the serialization of message consumption per
group. Generally speaking this flies in the face of clustering which is
designed to increase message throughput. In other words, if you're grouping
messages there's a good chance you can get the performance you need from a
single broker. This is similar to the "global ordering" issue we discussed
on an earlier thread.
Did you run performance benchmarks to determine you needed to cluster in
order to achieve your performance goals? I asked this on a previous thread
but didn't receive a response.
Your are right I didn't reply your question regarding performance
benchmarks. I do not have real performance benchmarks just reviewing our
architecture, I totally understand your point regarding using a single
broker, I am just looking for different ways of scaling in case of needing
and as a learning process, because is ok going with a single broker (knowing
that in the future I will not able to scale out if needed).
We have several pieces in our architecture and just one of them needs the
message group functionality to ensure a serial processing for a specific
group of messages.
I continue testing the message group functionality but I am not sure if I am
missing something because I was not able to rebalance groups. I tried using
address-settings(default-group-rebalance), manually invoking resetAllGroups
and using "?group-rebalance=true".
Artemis 2.9.0 - 2 Nodes - Cluster UDP
Queue: State (LVQ: Yes, Durable: Yes, Rebalance: Yes)