The issue you describe with the routed message count looks like a bug. Can you open a Jira?
Justin On Mon, Jul 8, 2024 at 12:43 PM Alexander Milovidov <milovid...@gmail.com> wrote: > Hi Justin, > > Thanks for the detailed answer. Of course IBM MQ and ActiveMQ Artemis > brokers have fundamental differences. I will try to explain the difference > to the users and instruct them how to send messages. > > And it is great that Artemis is in active development. Some users just > don't like any changes. > > Recently I have faced a strange situation when messages which do not match > the filter were delivered to the queue. These messages were redelivered > between cluster nodes. I think if we were running the latest version where > this bug is fixed, it could not happen. I would also like to reproduce this > situation, but it is difficult (at least I mentioned that something wrong > happened with the cluster after the replication between its two nodes has > been broken). > > About routed message count which increases when a message is not delivered > to any binding. It's easy to reproduce: > 1. Create a new Artemis instance. > 2. Create address TEST with multicast routing. > 3. Create a multicast queue TEST.FILTER with filter e.g. key='value' on > this address. > 4. Send a test message: > artemis producer --user=admin --password=admin --url=tcp://localhost:61616 > --message-count=1 --destination=topic://TEST > The message is not delivered to the queue, but the routed message count is > increased. > It also happens when sending a message to FQQN > destination=topic://TEST::TEST.FILTER. > > > пн, 8 июл. 2024 г. в 19:18, Justin Bertram <jbert...@apache.org>: > > > > Was it definitely a bug? > > > > Yes. I believe it was. > > > > > As I thought before, the filter is something that stands between > address > > and queue. > > > > Your assumption here isn't based on how the broker is actually designed. > > The filter is actually part of the queue itself. As the documentation [1] > > states: > > > > Only messages that match the filter expression will enter the queue. > > > > > When a user wants to send a message to the multicast queue, it is > usually > > done with testing purposes, or to make some application support tasks... > > > > This may be true of your use-case, but other valid use-cases exist. > > > > > IMHO this update breaks the logic of message processing and causes > extra > > work for users that support applications. > > > > Is it not possible to send a message that actually conforms to the > queue's > > filter? > > > > > Our testers are not fully disappointed because they still can send > > messages without headers to the multicast queue using the management > > console...I hope there are no plans to remove this option in the future. > > > > I just checked this use-case, and I can confirm that it works as you > > indicate. This is because it's not actually using the FQQN but rather an > > internal mechanism which circumvents the logic that evaluates the filter. > > My feeling is that it should probably be changed in order to be > consistent. > > > > > ...when messages are dropped, the routed message count of the address > is > > increased, and unrouted message count of the address is not increased. Is > > this correct? > > > > The definition of "routed message count" is: > > > > number of messages routed to one or more bindings > > > > So, if the message was routed to _at least one_ binding then the routed > > message count will increase. It's not clear from your description exactly > > what exactly is happening in your use-case. Is the message not routed to > > _any_ binding (e.g. due to filters) and the routed message count is still > > increasing? > > > > > > Justin > > > > On Fri, Jul 5, 2024 at 7:34 AM Alexander Milovidov <milovid...@gmail.com > > > > wrote: > > > > > Hi All, > > > > > > Recently I upgraded Artemis to 2.35.0 in the test environment and our > > > testers complained that they no longer can send messages to multicast > > > queues using FQQN. I have read release notes and found that there was a > > bug > > > that was fixed in this version. > > > Issue https://issues.apache.org/jira/browse/ARTEMIS-4795 > > > > > > I have some questions about this issue: > > > > > > 1. Was it definitely a bug? As I thought before, the filter is > something > > > that stands between address and queue. When an application sends a > > message > > > to the address, it is delivered to any queue on this address after > > passing > > > its filter. So the order of message processing is: address - filter - > > > queue. When we send a message directly to the queue using FQQN, we > don't > > > need to filter it - the filter is only needed when receiving messages > > that > > > are sent to an address. > > > 2. When a user wants to send a message to the multicast queue, it is > > > usually done with testing purposes, or to make some application support > > > tasks, for example to resend failed or lost messages. The intention is > to > > > put a message in a particular queue. A person who sends a message to > the > > > particular multicast queue usually knows what he (or she) does and the > > > message is not sent to the address with all multicast queues. Usually > we > > > don't need to additionally filter these messages. > > > > > > IMHO this update breaks the logic of message processing and causes > extra > > > work for users that support applications. > > > Our testers are not fully disappointed because they still can send > > > messages without headers to the multicast queue using the management > > > console. But this method is suitable for sending only a very small > > > number of messages. > > > I hope there are no plans to remove this option in the future. > > > > > > Another problem regarding sending messages to FQQN is that when > messages > > > are dropped, the routed message count of the address is increased, and > > > unrouted message count of the address is not increased. Is this > correct? > > > > > > -- > > > Regards, > > > Alexander > > > > > >
