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 > >
