> I think it is based on experience with IBM MQ. IBM MQ and ActiveMQ Artemis are, of course, 100% independent message broker implementations. There is overlap in general function and nomenclature, but past that there are many differences. Expectations will need to be adjusted accordingly.
> Another problem for Artemis users is that it is still in the active development and sometimes changes happen too suddenly. Some parts of the code-base are brand new. Some parts haven't changed in any meaningful way in over a decade. Does new development introduce new bugs or cause regressions? Of course. Overall, I'd say that active development is very good for users because they can get bugs fixed and new features implemented. Justin On Sat, Jul 6, 2024 at 3:22 PM Alexander Milovidov <milovid...@gmail.com> wrote: > 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 > > > > > >
