You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Ken Giusti (JIRA)" <ji...@apache.org> on 2015/10/28 15:55:27 UTC
[jira] [Commented] (PROTON-905) Long-lived connections leak
sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14978548#comment-14978548 ]
Ken Giusti commented on PROTON-905:
-----------------------------------
I think that we should bump this off until post 0.11 and bump the priority down to major.
This bug doesn't affect any application that uses proton's event-based processing model. This model is the preferred usage (as opposed to the 'walk all {links,deliveries,sessions} looking for work to do).
AFAIK - all the proton client code now uses the event-based approach.
I've tested this against qpidd-0.34 (event-based implementation) and there is no memory buildup.
Lastly, this is not a regression as it's been present at least as far back as the 0.9 series.
> Long-lived connections leak sessions and links
> ----------------------------------------------
>
> Key: PROTON-905
> URL: https://issues.apache.org/jira/browse/PROTON-905
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.9.1, 0.10
> Reporter: Ken Giusti
> Assignee: Rafael H. Schloming
> Priority: Critical
> Fix For: 0.11
>
> Attachments: test-send.py
>
>
> I found this issue while debugging a crash dump of qpidd.
> Long lived connections do not free its sessions/link.
> This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case.
> Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached.
> Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up.
> On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one.
> Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)