[
https://issues.apache.org/jira/browse/ARTEMIS-2007?focusedWorklogId=650462&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-650462
]
ASF GitHub Bot logged work on ARTEMIS-2007:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Sep/21 09:45
Start Date: 14/Sep/21 09:45
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3742:
URL: https://github.com/apache/activemq-artemis/pull/3742#discussion_r708099362
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
##########
@@ -3082,9 +3055,7 @@ private boolean deliver() {
numNoMatch = 0;
numAttempts = 0;
- if (consumer != redistributor) {
- ref = handleMessageGroup(ref, consumer, groupConsumer,
groupID);
- }
+ ref = handleMessageGroup(ref, consumer, groupConsumer,
groupID);
Review comment:
Not particularly no. Neither does the one for 'HANDLED' entirely. Both
seem to suggest it will always prefer earlier consumers until they arent 'busy
enough' to let it try others. Though it wont then try the others if there is a
'NO_MATCH', it will try the earlier ones again even if still busy.
Looking over it several times now, there is at least the fact that adding a
consumer always cancels the redistributor during the process, removing it
before adding the new consumer to the consumer list, so the redistributor
shouldnt ever end up in the middle of the list...so the reset in the
redistributor case shouldn't really be different than hitting the end of the
list.
The only other thing I do see for the non-distributor case is that you
apparently need to call reset to see updates to the consumer list (such as the
above new consumer), which can change as the loop is processing due to the fact
it goes in and out of the synchronization. Kind of feels like the obvious point
for that is at the end of the existing entries though rather on the first
no-match.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 650462)
Time Spent: 12.5h (was: 12h 20m)
> Messages not redistributed to consumers with matching filters when local non
> matching consumers are present
> -----------------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-2007
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2007
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: AMQP, Broker
> Affects Versions: 2.6.3
> Reporter: Sebastian T
> Assignee: Gary Tully
> Priority: Major
> Fix For: 2.19.0
>
> Attachments: AMQ2007Test.java, artemis-2007.zip
>
> Time Spent: 12.5h
> Remaining Estimate: 0h
>
> We are experiencing the following issue:
> # We configure an Artemis cluster with ON_DEMAND message loadbalacing and
> message redistribution enabled.
> # We then connect a single consumer to *queues.queue1* on node1 that has a
> message filter that does NOT match a given message.
> # Then we send a message to *queues.queue1* on node1.
> # Then we connect a consumer to *queues.queue1* on node2 that has a filter
> matching the message we sent.
> We now would expect that the message on node1 currently not having any
> matching consumers on node1 to be forwarded or redistributed to node2 where a
> matching consumer exists.
> However that is not happening the consumer on node2 does not receive the
> message and in our case the message on node1 expires after some time despite
> a matching consumer is connected to the cluster.
> In the described scenario when we disconnect the consumer on node1 (that does
> not match the message anyway) the message is redistributed to node2 and
> consumed by the matching consumer.
> If no consumer was connected to node1, a message is sent to node1 and only
> then a matching consumer is connected to node2 the message is forwarded to
> node2 as expected.
> So I guess the core problem is that message redistribution of messages on
> node1 is not triggered when a matching consumer is connected to node2 while a
> *any* consumer already exists on node1 no matter if it actually matches the
> given message.
> I attached a maven test case that illustrates the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
