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] [Comment Edited] (PROTON-850) inconsistent state when reusing link name
Date Thu, 16 Apr 2015 17:43:59 GMT

    [ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498365#comment-14498365
] 

Gordon Sim edited comment on PROTON-850 at 4/16/15 5:43 PM:
------------------------------------------------------------

This is an example using the plain reactor api, that follows the same pattern as the reproducer
attached to QPID-6320. Sample output as follows:

{noformat}
PN_LINK_LOCAL_OPEN(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
[0x22134f0]:  -> SASL
[0x22134f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
[0x22134f0]:  <- SASL
[0x22134f0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x22134f0]:0 <- @sasl-outcome(68) [code=0]
[0x22134f0]:  -> AMQP
[0x22134f0]:0 -> @open(16) [container-id="", hostname="localhost"]
[0x22134f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:  <- AMQP
[0x22134f0]:0 <- @open(16) [container-id="ba1d5e12-b282-491c-965d-32fd9bd44ab1"]
[0x22134f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
PN_LINK_FLOW(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
[0x22134f0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1", message-format=0,
settled=true, more=false] (75) "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d@@@@@@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\x09message-0"
[0x22134f0]:0 -> @detach(22) [handle=0, closed=true]
PN_LINK_LOCAL_CLOSE(<proton.Sender 0x7fe4858c6b90 ~ 0x22104f0>)
PN_LINK_FLOW(<proton.Sender 0x7fe4858c6b90 ~ 0x22104f0>)
[0x22134f0]:0 <- @detach(22) [handle=0, closed=true]
PN_LINK_REMOTE_CLOSE(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)
PN_LINK_LOCAL_OPEN(<proton.Sender 0x7fe4858c6ed0 ~ 0x2226e80>)

^^^^ Note a new link object associated with the local open....

[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)

^^^^ but the remote is associated with the old link object

PN_LINK_FLOW(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)
{noformat}



was (Author: gsim):
This is an example using the plain reactor api, that follows the same pattern as the reproducer
attached to QPID-6320. Sample output as follows:

{noformat}
PN_LINK_LOCAL_OPEN(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
[0x22134f0]:  -> SASL
[0x22134f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
[0x22134f0]:  <- SASL
[0x22134f0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x22134f0]:0 <- @sasl-outcome(68) [code=0]
[0x22134f0]:  -> AMQP
[0x22134f0]:0 -> @open(16) [container-id="", hostname="localhost"]
[0x22134f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:  <- AMQP
[0x22134f0]:0 <- @open(16) [container-id="ba1d5e12-b282-491c-965d-32fd9bd44ab1"]
[0x22134f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
PN_LINK_FLOW(<proton.Sender 0x7fe4858c6c90 ~ 0x22104f0>)
[0x22134f0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1", message-format=0,
settled=true, more=false] (75) "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d@@@@@@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\x09message-0"
[0x22134f0]:0 -> @detach(22) [handle=0, closed=true]
PN_LINK_LOCAL_CLOSE(<proton.Sender 0x7fe4858c6b90 ~ 0x22104f0>)
PN_LINK_FLOW(<proton.Sender 0x7fe4858c6b90 ~ 0x22104f0>)
[0x22134f0]:0 <- @detach(22) [handle=0, closed=true]
PN_LINK_REMOTE_CLOSE(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)
PN_LINK_LOCAL_OPEN(<proton.Sender 0x7fe4858c6ed0 ~ 0x2226e80>)
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)
PN_LINK_FLOW(<proton.Sender 0x7fe4858c6ed0 ~ 0x22104f0>)
{noformat}

> 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
>         Attachments: PROTON_850.py
>
>
> 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