ActiveMQ Artemis will dispatch messages to the consumers on a queue as quickly as possible without regard to any kind of round-robin distribution. The idea of round-robin distribution might seem good, but it typically doesn't work well in practice, especially in complex use-cases with consumers running in all kinds of different environments all processing messages at different rates. Instead of being managed by a fixed algorithm on the broker, distribution (aka balance) is managed via flow control [1] which is set independently by each consumer (i.e. via consumerWindowSize). It's not perfect, but this approach is much more flexible and can provide much higher overall message throughput then something like strict round-robin distribution.
The balance you need to strike when tuning consumerWindowSize for the consumers in your environment mainly involves to things: 1) Minimize network round-trips to the broker to get messages. For example, if the consumer is fast enough to empty its local buffer quickly then it may spend too much time fetching messages from the broker reducing performance. 2) Minimize any glut of messages in the consumer's buffer which might lead to the starvation of other consumers. For example, if the consumer is slow and has lots of messages in its local buffer then other faster consumers may starve for messages since the slow one is holding them. It sounds to me like in your environment you're hitting #2. In other words, the MDB instances on one app server are receiving all the messages into their local buffer effectively starving the MDB instances on the other app server. Therefore, I recommend you tune the value of the consumerWindowSize activation configuration property on your MDBs. You should also think about _how many_ sessions instances of the MDB you have configured as well. Each session will have its own consumer and therefore its own buffer. The consumer will then pass the message to the corresponding MDB instance. In contrast to normal JMS application clients application servers are typically set up to provide a fair amount of concurrent processing. If you're trying to balance message distribution between app server instances you may need to reduce that. If you don't really care about performance and want flat distribution among consumers then simply set consumerWindowSize=0 on all of them. However, even in that case you'll need to keep an eye on consumption concurrency on each app server instance. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/flow-control.html#flow-control On Wed, Aug 21, 2024 at 1:47 PM Claudio.Giacomossi <claudio.giacomo...@senior.com.br.invalid> wrote: > Hello everyone! > > I'm migrating a Java application to use the WildFly server and the Artemis > broker. I've already opened a ticket with the WildFly team ( > https://issues.redhat.com/browse/WFLY-19528), but I'm still without a > solution. > I need to balance the JMS queues between the WildFly servers that connect > to the remote Artemis, but what's happening is that all the messages are > being redirected to just one server (node in WildFly). The ticket has > additional information. > My question is whether Artemis shouldn't be performing this load balancing > in round-robin mode? > Att, > > Claudio > > > > > > > > > > > > AVISO LEGAL: Esta mensagem, incluindo seus anexos, ? destinada > exclusivamente para a(s) pessoa(s) a quem ela ? dirigida, podendo conter > informa??o confidencial e/ou privilegiada. Cabe a seus destinat?rios, > inclusive aqueles em c?pia, trat?-la adequadamente e com observ?ncia da > legisla??o em vigor. Est? proibida a sua divulga??o, reprodu??o e > distribui??o sem a devida autoriza??o. A inobserv?ncia das proibi??es ser? > pass?vel de aplica??o de san??es c?veis, criminais e disciplinares, quando > cab?veis. Se voc? recebeu esta mensagem indevidamente, antes de remov?-la > de sua caixa postal, entre em contato com o remetente para informar o > ocorrido. >
