[
https://issues.apache.org/jira/browse/ARTEMIS-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523818#comment-16523818
]
Justin Bertram commented on ARTEMIS-1932:
-----------------------------------------
bq. So if one consumer subscribes to a wildcard destination and then later
unsubscribes, then the new messages will still pile up forever in this wildcard
queue that has just been used once.
Assuming:
* The subscriber/consumer is using anycast semantics
* Auto-creation is enabled
* Auto-deletion is disable
Then the broker will auto-create an anycast address and queue and will not
auto-delete them. This is true regardless of whether or not the address uses
wildcards. The behavior is consistent with the configuration.
bq. I have the feeling that the wildcard subscriptions, just like the topic
subscriptions, should be temporary and should be destroyed when the client
unsubscribes, regardless of the auto delete setting.
If the application needs the semantics of a topic subscription the
configuration should reflect that (i.e. it should use multicast rather than
anycast). I believe that would provide the behavior you're looking for.
Changing the behavior here for wildcards would result be inconsistent and would
break any user relying on the existing behavior.
> 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)
