[jira] [Commented] (ARTEMIS-5337) Consumer + auto-create receives from existing wildcard queue

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937114#comment-17937114 ] 

ASF subversion and git services commented on ARTEMIS-5337:
----------------------------------------------------------

Commit 8dfe0a8d99811c270f46f7f077f08ca0321b6927 in activemq-artemis's branch refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8dfe0a8d99 ]

ARTEMIS-5337 consumer + auto-create receives from existing wildcard queue

Most protocols don't natively understand the address/queue model used by
Artemis. When those protocols want anycast semantics the standard
behavior is to create an address and a queue with the same name.
However, sometimes a queue already exists on the address with that
particular name in which case the broker will attach the consumer to
that queue.

This is acceptable most of the time, but it is problematic when that
queue uses a wild-card. In this case the consumer will potentially
receive messages sent to other addresses (i.e. whatever the wild-card
covers).

This commit fixes that by detecting the wild-card queue and ignoring it.
Instead the broker will create a new queue specifically for the incoming
consumer.


> Consumer + auto-create receives from existing wildcard queue
> ------------------------------------------------------------
>
>                 Key: ARTEMIS-5337
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-5337
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: AMQP, Broker
>    Affects Versions: 2.31.2, 2.38.0
>            Reporter: Jelle Smits
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> *Issue*
> In my setup where I have numerous consumers on explicitly defined queues (e.g. `queue.eventA.send, `queue.eventB.send`). These queues are auto-created and also have auto-delete turned on. Recently I added a wildcard consumer on `queue.*.send`, and noticed that after restarts of part of my applications, I occasionally get a consumer that _should_ be consuming on the specific queues
> (e.g. `queue.eventA.send`) suddenly starts consuming from `queue.*.send` instead, giving that queue 2 consumers instead of the expected 1. 
> *Reproduction*
> I'm able to consistently reproduce the issue, but it's difficult to share as it relies on some Docker containers with my applications. High-over, it should be easily reproducible in a testcase as well:
>  # Start a clean environment that initializes the following consumers (in any order):
>  ## queue.eventA.send
>  ## queue.eventB.send
>  ## queue.*.send
>  # Stop the consumers on `queue.eventA.send` and `queue.eventB.send`.
>  # Wait until the queues are auto-removed as the queues now have 0 consumers (and 0 messages) (i.e. AMQ224112 logging appears)
>  # Start the consumers again
>  ## The queues won't be auto-created now
>  ## The consumers will start consuming from the `queue.*.send` queue -> its consumer count will raise from 1 to 3
> If you were to do the same but the 'eventB' queue is not auto-deleted, that consumer will work just fine. 
>  
> To me, it feels like some internal divert remains when the queue is auto-deleted, causing it to not be created again and therefore messing up how my messages are consumed. Is this expected behavior? 
>  
> My (relevant) address settings are:
>  * Address full policy = Page
>  * Auto create addresses / queues = true
>  * Auto delete addresses / queus = true -> when I switch this to false I can prevent the issue from occuring
>  * Auto create dead letter & expiry resources = false
>  * Routing type: Anycast
>  * Address pattern: queue.#
>  
> I tested on the 2 artemis versions mentioned. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@activemq.apache.org
For additional commands, e-mail: issues-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact