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