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

Lionel Cons commented on ARTEMIS-1932:
--------------------------------------

bq. The explicit function of the wildcard address is to aggregate messages sent 
to other addresses which match the wildcard address' name.

Agreed but this is not the point here. The problem is that Artemis creates a 
permanent binding that stays even after the consumer unsubscribes.

Just like for ARTEMIS-1933, the behavior of Artemis differs from ActiveMQ 5.x. 
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).

Just like ARTEMIS-1933, which option do you think applies here?

> 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)

Reply via email to