Done. https://issues.apache.org/jira/browse/ARTEMIS-4911
пн, 8 июл. 2024 г. в 21:22, Justin Bertram <jbert...@apache.org>: > 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 > > > > > > > > > >
