Thanks!
Justin On Mon, Jul 8, 2024 at 2:49 PM Alexander Milovidov <milovid...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > >
