qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Sim (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PROTON-850) inconsistent state when reusing link name
Date Thu, 16 Apr 2015 17:39:59 GMT

     [ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gordon Sim updated PROTON-850:
------------------------------
    Component/s: python-binding
    Description: 
If a link is closed, and a new link with the same name is created and opened, the attach received
for the second link from the peer is applied to the old link.

If the old link is freed after being closed, this is avoided, but I'm not sure that is possible
via e.g. the python bindings.

The root of the problem I think is that a handle is reused after the link is closed, whether
freed or not, but when processing an incoming attach, it is the link name that is used to
find the appropriate link, which iterates through all links until it matches one by name,
which in this case is the old, closed link.


  was:
See also QPID=6320

If a peer closes a link, then opens another with the same name, at the point the new PN_LINK_REMOTE_OPEN
event is emitted, the link state for the lnk associated with that event is 20 (i.e. LOCAL_CLOSED
and REMOTE_ACTIVE).

        Summary: inconsistent state when reusing link name  (was: link state is incorrect
after detach and reattach with same name)

> inconsistent state when reusing link name
> -----------------------------------------
>
>                 Key: PROTON-850
>                 URL: https://issues.apache.org/jira/browse/PROTON-850
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c, python-binding
>    Affects Versions: 0.9
>            Reporter: Gordon Sim
>
> If a link is closed, and a new link with the same name is created and opened, the attach
received for the second link from the peer is applied to the old link.
> If the old link is freed after being closed, this is avoided, but I'm not sure that is
possible via e.g. the python bindings.
> The root of the problem I think is that a handle is reused after the link is closed,
whether freed or not, but when processing an incoming attach, it is the link name that is
used to find the appropriate link, which iterates through all links until it matches one by
name, which in this case is the old, closed link.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message