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

Robbie Gemmell reassigned QPID-3157:
------------------------------------

    Assignee: Keith Wall  (was: Robbie Gemmell)

Hi Keith, could you review these changes please?

The SubscriptionList now ensures it removes the nodes during the remove method 
rather than waiting for the list head to advance past them, which may not occur 
if earlier Subscription nodes in the list remain active. A dummy node is 
inserted at the end when attempting to remove the current tail node, as the 
tail cant be unlinked for thread safety. The new 'marked node' functionlity 
within the SubscriptionList allows cleaning up any nodes the prior 
'lastSubscriptionNode' reference in the queue would have leaked by simply 
searching for the next non-deleted node after the marker, since this is 
guaranteed to be within the active list, after which point they are no longer 
leaked due to the above changes.

Thanks,
Robbie.

> 'removed' subscriptions may be held in memory by the queues SubscriptionList 
> or 'lastSubscriptionNode' reference
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-3157
>                 URL: https://issues.apache.org/jira/browse/QPID-3157
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12
>            Reporter: Robbie Gemmell
>            Assignee: Keith Wall
>            Priority: Critical
>             Fix For: 0.13
>
>
> subscriptions 'removed' from a queue subscription list are only marked 
> deleted and can not actually bereleased from memory until the head of the 
> subscription list advances beyond them. Additionally and perhaps more 
> troublesome, a queues 'lastSubscriptionNode' can refer to a particular 
> subscription but hold *all* subscequent subscriptions in memory whether they 
> have been deleted or not and regardless whether the head of the 
> SubscriptionList has advanced beyond them,
> As a result any memory in use by the now-closed subscription will not be 
> released until the queue is deleted, or all the subscriptions prior to it are 
> closed and removed from the list *and* the 'lastSubscriptionNode' advances 
> beyond them.. This also holds the associated ServerSession in memory, which 
> is currently a rather heavyweight object.
> This issue is further compounded when the queue has a backlog of messages and 
> consumers are then created, used to recieve one message, and closed. In this 
> scenario the broker sends the client as many messages as it can prefetch, 
> leading to creation of up to <prefetch size, default=500> MessageTransfer 
> commands, all which are recorded in the ServerSession but then left retained 
> as 'unprocessed' in the closed session, which might be held in memory as 
> described above. This results in an explosion in the number of 
> MessageTransfer commands retained in memory as each message can have up to 
> <prefetch size> MessageTransfer commands associated with it before it is 
> eventually consumed by a client and all of thse will also be retained in 
> memory by a 'removed' but not deleted subscription. The last effect can be 
> combated by restricting the preftech size (eg appending &maxprefetch='1' to 
> the connection url).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to