[
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)