> Justin, is the documentation wrong for the boolean values for the legacy forward-when-no-consumers attribute that it associates with STRICT and ON_DEMAND? It seems like STRICT should be false and ON_DEMAND should be true.
No, the documentation is accurate. When using STRICT then nodes will forward messages around the cluster round-robin regardless of the presence of consumers (i.e. forward-when-no-consumers=true) and vice-versa for ON_DEMAND. > The problem with message redistribution (just like 5.x's store-and-forward behavior in a network of brokers) is that it doesn't preserve message ordering within the queue. That's true. Message order can change in a cluster. However, for many use-cases this doesn't matter. Clustering is all about increasing message throughput via horizontal scaling (i.e. increasing potential concurrency). This works great for use-cases that don't require strict message order. However, just about any use-case where you implement clustering is going to be fundamentally at odds with use-cases requiring strict message ordering. Maintaining strict message order is a performance killer since it serializes message consumption (i.e. it precludes concurrent message processing). Scaling horizontally doesn't increase performance so clustering provides no real benefit. Furthermore, scaling horizontally only to then restrict the management of certain queues to one node also defeats the purpose of scaling since by definition there's no real scaling involved for those queues. All that said, Artemis does have clustered message grouping [1] where one node in the cluster acts as a decision point for which consumers should get grouped messages (i.e. messages that should be consumed in strict order). However, it gets used very rarely because the ordered use-case and the clustered architecture just don't really fit together. It doesn't scale well and it elevates the importance of the node making the decisions which upsets the idea of cluster node symmetry. In complex environments where both horizontal scaling and message ordering are essential it's usually best to just have a single node for all the clients that need strict ordering and then a cluster for all the clients that don't. Justin [1] http://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html#clustered-grouping On Wed, Dec 2, 2020 at 7:20 AM Tim Bain <tb...@alumni.duke.edu> wrote: > Justin, is the documentation wrong for the boolean values for the legacy > forward-when-no-consumers attribute that it associates with STRICT and > ON_DEMAND? It seems like STRICT should be false and ON_DEMAND should be > true. > > The problem with message redistribution (just like 5.x's store-and-forward > behavior in a network of brokers) is that it doesn't preserve message > ordering within the queue. I think a better architecture would be to store > messages for a given destination on a single node, and allow the node to > which the client is connected to act as a transparent proxy for the client > to write and consume messages from the node on which they live for that > destination. Then the client is unaware of the the complexities of which > node has which messages, and there's no need to shuffle messages between > the nodes in ways that break message ordering. > > Tim > > On Wed, Dec 2, 2020, 2:02 AM Magnus Andersson <magnus.anders...@kvadrat.se > > > wrote: > > > I do not see that redistribution for STRICT and OFF would solve the > > problem. > > > > The issue I see is the round-robin behavior. If the consumer is > > disconnected, and queues exists on all nodes, the incoming messages will > be > > round-robined among the nodes. And this means that the consumer must > > connect to all nodes in the cluster to retrieve all messages that have > been > > published meanwhile it was disconnected. Or is there another pattern to > > solve this? Using redistribution config would redistribute the message > > within X ms, but what if the consumer isn’t connected then? > > > > As I mentioned, we would like the nodes in the cluster to be behind a > > load-balancer to be able to scale the cluster seamlessly, but as I > > understand it reading the documentation durable consumers need to be > aware > > of the nodes in the cluster (to solve the above question). Or am I > > misunderstanding something? > > > > brgds > > Magnus > > > > > > > > > > This use-case requires message *redistribution* [1] which currently > > requires using the ON_DEMAND message load-balancing policy as described > in > > the documentation. Since you're using STRICT you won't get message > > redistribution. > > > > Note, I sent a PR [2] over a year ago to support redistribution with both > > STRICT and OFF message load-balancing policies, but it got bogged down in > > disagreements about naming. If you really want to use STRICT message load > > balancing with redistribution then please comment on that PR and let me > > know. > > > > > > Justin > > > > [1] > > > > > http://activemq.apache.org/components/artemis/documentation/latest/clusters.html#message-redistribution > > [2] https://github.com/apache/activemq-artemis/pull/2893 > > > > On Tue, Dec 1, 2020 at 8:37 AM Magnus Andersson < > mag_anders...@hotmail.com > > > > > wrote: > > > > > Hello, > > > We are running Artemis in a clustered setup with three nodes. We have a > > > load balancer in front of the nodes. > > > > > > We want a durable subscriber to be unaware of which node it connects > to. > > > So if the durable subscriber loose connection to instance nodeA, it can > > > connect to nodeB (which it hasn’t been connected to before) and get all > > > messages published meanwhile it was disconnected. > > > > > > How can we achive this? We have tried with predefined adresses and > > queues, > > > message-load-balancing set to STRICT. But then the messages are > > > round-robined between the nodes which the subscriber has been connected > > to. > > > And the subscriber need to connect to all of these nodes to get all > > > messages published meanwhile offline. > > > > > > For previous versions of apache active mq, i see there is the concept > of > > > virtual destinations and network of brokers. But I do not find this for > > > Artemis. > > > > > > Thanks for input! > > > > > > Brgds > > > Magnus Andersson > > > >
