osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GitHub] activemq-artemis pull request #2458: ARTEMIS-2199 PagingStore leak when dele...


GitHub user jbertram opened a pull request:

    https://github.com/apache/activemq-artemis/pull/2458

    ARTEMIS-2199 PagingStore leak when deleting queue

    When deleting a queue the JMSPostQueueDeletionCallback#callback will
    invoke PostOfficeImpl#getBindingsForAddress which will *create* a
    Bindings instance if one doesn't exist. This will trigger the creation
    of a PagingStore instance which will be stored by the PagingManager
    and may never be deleted. This is particularly problematic for use-cases
    involving temporary JMS queues.
    
    This change uses the lookupBindingsForAddress instead of
    getBindingsForAddress which doesn't implicitly create a Bindings
    instance.
    
    This problem doesn't exist on the master branch as the
    JMSPostQueueDeletionCallback no longer exists there.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2199

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-artemis/pull/2458.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2458
    
----
commit 6032fce45703d57be7e0a2542b443508674c406a
Author: Justin Bertram <jbertram@...>
Date:   2018-12-10T18:13:37Z

    ARTEMIS-2199 PagingStore leak when deleting queue
    
    When deleting a queue the JMSPostQueueDeletionCallback#callback will
    invoke PostOfficeImpl#getBindingsForAddress which will *create* a
    Bindings instance if one doesn't exist. This will trigger the creation
    of a PagingStore instance which will be stored by the PagingManager
    and may never be deleted. This is particularly problematic for use-cases
    involving temporary JMS queues.
    
    This change uses the lookupBindingsForAddress instead of
    getBindingsForAddress which doesn't implicitly create a Bindings
    instance.
    
    This problem doesn't exist on the master branch as the
    JMSPostQueueDeletionCallback no longer exists there.

----


---