[
https://issues.apache.org/jira/browse/ARTEMIS-4259?focusedWorklogId=859395&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859395
]
ASF GitHub Bot logged work on ARTEMIS-4259:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 27/Apr/23 11:42
Start Date: 27/Apr/23 11:42
Worklog Time Spent: 10m
Work Description: gemmellr commented on PR #4452:
URL:
https://github.com/apache/activemq-artemis/pull/4452#issuecomment-1525545220
More specifically, auto-created 'topic consumer + FQQN + filter' queues, and
expecting that only messages matching that consumers filter will get to the
created queue, and ultimately the consumer?
Looks like for Core, it didnt do any filtering at all for the auto-created
FQQN+filter case, as neither queue creation or consumer had a filter applied.
For AMQP, it looks like the consumers are filtered, but the queue wasnt and
thus would get all messages on the address and retain any that dont match the
consumer(s) filter(s). If a pre-created queue existed with an appropriate
filter, it seems like it would have worked for both.
This change looks like it fixes the auto-creation case, though seems like it
would introduce and/or retain some oddities for working with existing queues
either pre-defined or previously auto-created (plus may even prevent some niche
things that worked before).
For queues that already exist and that either have no filter or have a
different filter than a new consumer uses, it doesnt seem like it will be
noticed since nothing is done with the queue filter when the queue already
exists. For Core that seems like it could mean if the existing queue has no
filter it still does no filtering even when its desired it should , and for the
mismatched-filters case it might actually filter the 'wrong thing' and again
allow non-matching messages to get to the consumer, since it still looks to
rely solely on the hopefully-existing-and-hopefully-matching queue filter
alone, with no consumer filter put in place at all. For AMQP, it seems it could
once again pile up any messages that dont match the new consumers filter for
the no-existing-queue-filter case (since it will still get all messages but the
consumer will be filtered), and in the mismatched filter case it may not get
all messages it 'should' and may pile up unmatched messages again since the
queue filter doesnt match the consumers, though at least no 'non-matching'
messages would get to the consumer due to its filter (note it will often be
double-filtering though since both queue and consumer can have filters).
Its not clear to me what can/should be done about that. Document it and
ignore? Check if queue is filtered and throw if there is a mismatch (but that
might actually be deliberate for a pre-defined queue filter..)? (For regular
JMS durable subs the existing sub is to be seamlessly destroyed and a fresh sub
begun when filter changes..same for shared subs, if not currently in use by
others).
One thing is this could prevent some existing possible niche behaviours.
Previously it seems you could perhaps have had multiple filtered AMQP consumers
having different filters pulling from the same FQQN (say, structured such that
all messages could be consumed by someone). This will break such things for
auto-created usage, since the queue would now be filtered based only on the
first/creating consumers filter. JMS specifically doesnt allow such stuff with
regular shared subs though, everyone has to use same filter for this reason.
Issue Time Tracking
-------------------
Worklog Id: (was: 859395)
Remaining Estimate: 0h
Time Spent: 10m
> JMS topic + FQQN + filter not working
> -------------------------------------
>
> Key: ARTEMIS-4259
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4259
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The CORE protocol does not honor consumers with a filter when used on FQQN
> topics.
> Steps to reproduce:
> Start a consumer using CLI:
> {noformat}
> ./artemis consumer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --filter
> "foo='bar'" --verbose{noformat}
> Send a message without the filter string:
> {noformat}
> ./artemis producer --url tcp://localhost:61616 --destination
> topic://topic1::topic1.queue1 --protocol=core --message-count 1 --message
> "some text"{noformat}
> You can observe the CORE client consuming the message which does not contain
> the filter String:
> {noformat}
> Connection brokerURL = tcp://localhost:61616
> Consumer:: filter = foo='bar'
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 wait until 1 messages
> are consumed
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Received some text
> JMS Message ID:ID:a00cbea3-dda7-11ed-9c2d-b42e99ea6f5c
> Received text sized at 9
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in
> second : 8 s
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Elapsed time in milli
> second : 8140 milli seconds
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumed: 1 messages
> Consumer ActiveMQTopic[topic1::topic1.queue1], thread=0 Consumer thread
> finished{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
