Uploaded image for project: 'ActiveMQ'
  1. ActiveMQ
  2. AMQ-6254

Durable wildcard subscription causes memory leak after broker restart

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.11.1, 5.12.2
    • Fix Version/s: 5.13.3, 5.14.0
    • Component/s: Broker
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tabish Timothy Bish
                Reporter:
                osmanrafiq Osman Rafiq
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: