[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644747#comment-14644747 ]
ASF subversion and git services commented on PROTON-905: -------------------------------------------------------- Commit 4c84dd7c3c708fd823116876cd65885a628f92ff in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4c84dd7 ] PROTON-905: Revert "PROTON-905: fix to prevent crash with latest qpidd" This reverts commit d9ce3cfd0916ae3719cb39a83a6174c5f88b10bb. The latest qpidd is crashing due to the PROTON-905 fix whilst running the HA tests. > 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 > Reporter: Ken Giusti > Assignee: Rafael H. Schloming > Priority: Critical > Fix For: 0.10 > > 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)