> 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
>
