You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Osman Rafiq (JIRA)" <ji...@apache.org> on 2016/04/15 10:49:25 UTC

[jira] [Updated] (AMQ-6254) Durable wildcard subscription causes memory leak after broker restart

     [ https://issues.apache.org/jira/browse/AMQ-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osman Rafiq updated AMQ-6254:
-----------------------------
    Attachment: DurableWildcardSubscriptionReactivationTest.java

Attaching a unit test that shows the existence of another subscription after broker restart. 

Note: The test uses inner classes from SimpleSecurityBrokerSystemTest because I needed the authentication/authorization plugin configured on the broker and got a bit lazy.

> Durable wildcard subscription causes memory leak after broker restart
> ---------------------------------------------------------------------
>
>                 Key: AMQ-6254
>                 URL: https://issues.apache.org/jira/browse/AMQ-6254
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.11.1, 5.12.2
>            Reporter: Osman Rafiq
>         Attachments: DurableWildcardSubscriptionReactivationTest.java
>
>
> We have two setups using ActiveMQ 5.11.1 and 5.12.2 that are both configured with authentication/authorization and are using LevelDB for persistence.
> We have observed an issue with durable wildcard subscribers where it seems that a durable subscriber restored after a broker restart is not being replaced/updated when the subscriber reconnects after the restart. Instead both the restored and reconnected durable subscribers are being kept by the broker.
> An example may help to clarify the issue:
> *Before restart*:
> Topic: alphabet.a
> Durable subscriber: aplhabet.>
> *After restart*:
> Durable subscriber: alphabet.a
> *After reconnect*:
> Durable subscriber: aplhabet.a
> Durable subscriber: alphabet.>
> As messages sent to the topic are forwarded to both the restored and reconnected durable subscriber, but the restored subscriber is never being dequeued it consumes ever increasing amounts of memory.
> The issue is related to AMQ-5153 as the restored subscriber has an incorrect subscribed destination (i.e. alhpabet.a instead of alphabet.>). 
> However, the restored and reconnected durable subscribers only come into co-existence if the broker is run with broker plugins (i.e. authorization/authentication) as the use of DestinationFilters prevents the TopicRegion from running through all known Topics to remove possible matching subscriptions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)