You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Gordon Sim (JIRA)" <ji...@apache.org> on 2015/04/16 19:43:59 UTC
[jira] [Comment Edited] (PROTON-850) inconsistent state when
reusing link name
[ 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)