[
https://issues.apache.org/jira/browse/ARTEMIS-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526683#comment-16526683
]
Justin Bertram commented on ARTEMIS-1932:
-----------------------------------------
bq. So either one of the two is wrong (and a bug should be fixed there) or they
have intentionally decided to implement things differently (and this must be
clearly documented).
I don't think any of these options actually captures reality. I don't think
either implementation is _wrong_, and the Artemis wildcard address
functionality was developed long before the Apache donation so no one
"intentionally decided to implement things differently." I believe each
implementation took shape on its own independently of the other.
The current discrepancy in behavior is based on fundamental differences between
the underlying implementations of wildcard functionality in each broker. As I
understand it, in 5.x the "destination wildcard" is essentially a way to create
a _consumer_ which will receive messages from destinations matching the
wildcard. However, in Artemis an actual _address_ is created with the wildcard
and queues on that address get the messages sent to addresses which match the
wildcard.
I _think_ you can achieve equivalent behavior to what you had before by using
multicast instead of anycast for your wildcard subscribers.
> Wildcard subscriptions create permanent bindings (STOMP)
> --------------------------------------------------------
>
> Key: ARTEMIS-1932
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1932
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Lionel Cons
> Priority: Major
> Attachments: ARTEMIS-1932.text, broker.xml
>
>
> When using STOMP to create a wildcard subscription to {{/queue/test.\*}},
> Artemis creates a {{/queue/test.\*}} address and an eponymous ANYCAST queue
> within. So far, so good.
> However, these automatically created objects are permanent and survive at the
> end of the connection.
> Here is the test scenario:
> - start with an empty broker
> - connect
> - subscribe to {{/queue/test.\*}}
> - unsubscribe
> - disconnect
> - bug => the address and queue remain
> - connect
> - send a message to {{/queue/test.foo}}
> - bug => the message appears in the {{/queue/test.\*}} queue (in addition to
> {{/queue/test.foo}})
> FWIW, I'm using {{default-address-routing-type}} to make sure destinations
> starting with {{/queue/}} act like a queue (see ARTEMIS-1906).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
