[
https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644748#comment-14644748
]
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)
