[ https://issues.apache.org/jira/browse/PROTON-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646214#comment-14646214 ]
ASF subversion and git services commented on PROTON-965: -------------------------------------------------------- Commit 172e6f0056c6eda34726b1143aab666d61886c0b in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=172e6f0 ] PROTON-965: remove leftover previous impl, let the following replacement impl decide whether it should remove from the map or not > [proton-j] freed receiver link may cause a removal from the wrong collection > in the session > ------------------------------------------------------------------------------------------- > > Key: PROTON-965 > URL: https://issues.apache.org/jira/browse/PROTON-965 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j > Affects Versions: 0.9.1 > Reporter: Robbie Gemmell > Assignee: Robbie Gemmell > Priority: Minor > Fix For: 0.10 > > > The changes for PROTON-853 contained a defect, as it left an old method call > in place that should have been removed. > When a receiver link object is free'd, the parent session is informed and > removes the link from a collection. Following PROTON-853 there are two such > collections, an existing map of current reciever links and a new list of old > stale links, of which the given object may be in one. The intent of the > SessionImpl#freeReceiver() method is to remove a receiver from the > appropriate list, however the old single-line > "_receivers.remove(receiver.getName());" implementation from before PRTON-853 > was somehow left in place meaning it is always called before the new > implementation follows which understands the dual collections. As a result, a > link object may be removed from the map incorrectly in certain cases (if it > happened to have the same name, but was a different object, from the freed > object). -- This message was sent by Atlassian JIRA (v6.3.4#6332)