There may be something that the RA is doing which triggers the broker to select a new consumer for each message in the group. Ultimately message grouping is designed to ensure that the messages are consumed sequentially in order (i.e. not concurrently). Typically that's done by selecting a single consumer that gets every message in the group, but it's conceivable that a different consumer could receive every message in the group. As long as the messages in the group are dispatched one by one when the previous message in the group has been acknowledged then the basic semantics of message grouping would still be fulfilled. This may be what's happening in your case, but it's not clear from your description.
Setting aside the fact that a different consumer is getting each message, are messages in the same group being consumed concurrently? If not, then I don't believe there's a functional problem. If so, then can you work up a test-case that I can use to reproduce the behavior you're seeing? Justin On Thu, May 23, 2024 at 3:00 AM Silvio Bierman <silvio.bier...@planonsoftware.com.invalid> wrote: > Thank you Betram for your comments. I will try to clarify inline. > > > > What observations are you making that lead you to this conclusion? > Please be specific. > > We kept record of the message groups used and the identity of the consumer > (MDB instance) handling the last message in each group and logged whenever > a message was assigned to a different consumer than the one that handled > the last message for the group. > We expected there to be no logging or at least each new consumer should be > a newly created instance replacing an earlier consumer instance. However, > we see many occurrences of this scenario logged with a fixed group of > consumer instances. In other words: we see message groups being handled by > different consumers constantly while the pool of consumer instances stays > the same. > > > ENTMQ-261 [1] is not from the official Apache Jira project for ActiveMQ > Artemis [2]. It appears to be from a Red Hat issue tracker for their > product based on ActiveMQ Classic. It is not connected to the release of > Apache ActiveMQ Classic 6.1, and I can find no mention of ENTMQ-261 in the > release notes for ActiveMQ Classic 6.1. > > Yes, I know that. That is why I was asking if the same issue might be > present in ActiveMQ Artemis assuming there might be overlap in the code > bases. > > > ActiveMQ Artemis is based on the HornetQ code-base which was donated to > Apache ActiveMQ almost 10 years ago now. If you read the description on > ENTMQ-261 you'll see that grouping was working as expected in HornetQ so I > expect it would still be working ActiveMQ Artemis unless there's been some > kind of regression that we're not aware of. > > OK, I think that answers my question then. > > > It's hard to say since the exact nature of the problem is still unclear. > At the very least I would recommend upgrading WildFly so you're on a later > release of ActiveMQ Artemis. Version 2.16.0 was released in late 2020 > almost 4 years ago now. Lots of bugs have been fixed since then. Even if > the problem you're seeing is a bug there won't be a bug-fix release for > 2.16.0. You'd need to upgrade to the latest version to get it. That said, > I'm still not sure this is actually a bug. > > We plan to upgrade Wildfly in the future so that may solve our issues. But > since that may not happen anytime soon I was wondering if there might be > some way to work around this. > > Thank you again for sharing your thoughts. > > Silvio > >
