Why, after all this time, are you moving to a clustered deployment? The fact that you require strictly ordered message processing means that processing will be quite slow, relatively speaking, which means performance is likely not a limiting factor in your use-case. Typically folks leverage clustering as a way to increase performance via horizontal scaling. Conceptually speaking, strictly ordered message processing and horizontal scaling don't mix well. This is briefly discussed in the documentation [1].
Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html#clustered-grouping On Fri, Jan 26, 2024 at 12:42 AM Sebastian Götz < s.go...@inform-technology.de> wrote: > Hello group, > > we were using ActiveMQ Artemis and it's predecessor HornetQ over years > now but never came to the point where we had to use clustering and ha. > Now this has changed and I have worked through the examples to setup a > ha cluster with 6 nodes (3 live, 3 backup). > > While this works like a charm I have some major problems in the way we > use the messaging I want to explain in the following. > We have some sort of network devices attached to our software and > changes to the configuration causes "orders" to be placed into an order > queue (only one global queue). While processing these orders, messages > are produced for devices and placed into an outbox queue (one per > device). Our requirement to this order queue is sequential processing > (the first message from a queue for a device has to be completely > processed before the next one is picked). So far we managed this using > the concept of grouping messages and filtering via a certain message > property (i.e. the device id). This offered the possibility to handle > this inside our software because the broker dispatches all messages with > the same group to the same consumer with the matching filter, which is > great. > Moreover we have a so called event topic where we distribute messages > between the parts of the software which is made up of several > independent processes. This is done through a classic topic (one address > with several queues attached). > > Node A Node B Node V > ___________ ___________ ___________ > |___QUEUE___| ||||QUEUE|||| |___QUEUE___| > | ^ | > | | | > | | | > Consumer 1 Producer Consumer 2 > > With clustering a big problem arises from these requirements (I tried to > picture that above): > For of the queues it is possible that the producer is connected to > node B and consumers connected to node A and C leading to B building up > a queue with a large message count while the two consumers starve. > > I already worked through the concepts of message redistribution, diverts > and bridges but none of them seems to solve this problem. Message > redistribution only kicks in, when there are no more consumers on a > queue of a distinct node. But for our order queue there might well be > several consumers on different nodes with different filters, so its > quite difficult to say which message should be dispatched to which node. > Diverting could do more on this but I do not see how this could work > with the concept of failover and failback, because we could never know > in advance to which of the available node a consumer would connect after > failover and its messages could well be all on a failed node. > We would like to see a queue as an abstract source of messages for the > consumers they can read from never mind to which node of the cluster > they are connected. I understand that this would mean that message > reception and removal would have to be replicated to all members of a > cluster (event the backup nodes) which would cause high load I guess. I > am hoping that someone has a hint for me how we could address this. > > Kind regards > > Sebastian > >
