[
https://issues.apache.org/jira/browse/ARTEMIS-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525350#comment-16525350
]
Justin Bertram commented on ARTEMIS-1932:
-----------------------------------------
bq. Indeed but there is a major difference: with wildcard subscriptions, the
messages will be held in a queue different from the one matching the
destination.
I believe I understand what you're saying here (i.e. messages may pile up in a
queue which isn't immediately obvious). However, it's not technically accurate
to say that, "messages will be held in a queue different from the one matching
the destination." If messages are put into a queue bound to a wildcard address
that means the wildcard address does in fact _match_ the STOMP destination
where the messages were sent. Messages are only ever put in queues with a
matching address whether the match literal or wildcard.
bq. I am still convinced that case 2 is not what messaging users expect from a
broker.
If queues bound to a wildcard address which match the address to which a
message is sent don't also receive those messages then I'm not sure I
understand the purpose of wildcard addresses at all. The explicit function of
the wildcard address is to aggregate messages sent to other addresses which
match the wildcard address' name. This is the essential behavior described in
the
[Artemis|https://activemq.apache.org/artemis/docs/latest/wildcard-routing.html]
and [ActiveMQ 5.x|http://activemq.apache.org/wildcards.html] documentation. If
users are not to expect this behavior from the broker what should they expect?
For what it's worth, if this behavior is not desired then it can be disabled
using:
{code:xml}
<wildcard-addresses>
<routing-enabled>false</routing-enabled>
</wildcard-addresses>
{code}
Wildcard addresses are certainly powerful so if there is a concern that a
misbehaving or malicious client might create a wildcard address and queue where
messages accumulate inappropriately then you could only grant {{createAddress}}
and/or {{createDurableQueue}} permissions to the clients you absolutely trust.
If the security option is not feasible or desirable then you could monitor the
broker for the creation of wildcard addresses. I see two options here:
# Implement a [broker
plugin|https://activemq.apache.org/artemis/docs/latest/broker-plugins.html]
which could alert you when a wildcard address is created.
# Configure the [notification
plugin|https://activemq.apache.org/artemis/docs/latest/broker-plugins.html#using-the-notificationactivemqserverplugin]
and listen for {{ADDRESS_ADDED}} [management
notifications|https://activemq.apache.org/artemis/docs/latest/management.html#management-notifications]
(e.g. using a selector like {{_AMQ_NotifType = '22'}}).
> 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)
