I think it is based on experience with IBM MQ. For many years, users have become accustomed to the fact that a queue is just a queue without any additional mechanisms such as filters. In IBM MQ there is no such thing like a filter on the queue. Another problem for Artemis users is that it is still in the active development and sometimes changes happen too suddenly. There is no problem if this bugfix was really needed (and someone has been affected by this bug).
сб, 6 июл. 2024 г. в 05:00, Clebert Suconic <clebert.suco...@gmail.com>: > I would say it was a bug. Why would you force a send when the filter does > not match ? > > Clebert Suconic > > > On Fri, Jul 5, 2024 at 8:33 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 > > >
