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 >