Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-850

inconsistent state when reusing link name

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.9
    • Fix Version/s: 0.9.1, 0.10
    • Component/s: proton-c, python-binding
    • Labels:
      None

      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.

        Issue Links

          Activity

          Hide
          gemmellr Robbie Gemmell added a comment -

          I have spent some time investigating a related issue on proton-j (which in 0.9 is actually emitting an attach it wasnt asked to, PROTON-853, due to changes to resolve what sounds like the behaviour you are describing, via PROTON-154) and comparing with what proton-c does. The main difference would seem to be I'm looking at it from the client side, whereas you are from the server side. You might be able to help me with some C'isms though

          Show
          gemmellr Robbie Gemmell added a comment - I have spent some time investigating a related issue on proton-j (which in 0.9 is actually emitting an attach it wasnt asked to, PROTON-853 , due to changes to resolve what sounds like the behaviour you are describing, via PROTON-154 ) and comparing with what proton-c does. The main difference would seem to be I'm looking at it from the client side, whereas you are from the server side. You might be able to help me with some C'isms though
          Hide
          gsim Gordon Sim added a comment - - edited

          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:

          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>)
          
          Show
          gsim Gordon Sim added a comment - - edited 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: 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>)
          Hide
          gsim Gordon Sim added a comment -
          Show
          gsim Gordon Sim added a comment - Proposed fix: https://reviews.apache.org/r/33300/
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit fd26ec66bcd1fda328ceca119efc43bf787e0bcf in qpid-proton's branch refs/heads/master from Gordon Sim
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fd26ec6 ]

          PROTON-850: ensure attach updates correct link object

          Show
          jira-bot ASF subversion and git services added a comment - Commit fd26ec66bcd1fda328ceca119efc43bf787e0bcf in qpid-proton's branch refs/heads/master from Gordon Sim [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fd26ec6 ] PROTON-850 : ensure attach updates correct link object
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch refs/heads/master from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ]

          PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ] PROTON-853 : add a test that catches the issue from PROTON-154 (and PROTON-850 )
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f2d7d669155a2ca57606c9381f4f1720739be79b in qpid-proton's branch refs/heads/master from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2d7d66 ]

          PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850.

          This closes #21

          Show
          jira-bot ASF subversion and git services added a comment - Commit f2d7d669155a2ca57606c9381f4f1720739be79b in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2d7d66 ] PROTON-853 : dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850 . This closes #21
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit acd1e1c9a582aaf190bb32ebc5bd9e590bd71930 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=acd1e1c ]

          PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)

          (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)

          Show
          jira-bot ASF subversion and git services added a comment - Commit acd1e1c9a582aaf190bb32ebc5bd9e590bd71930 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=acd1e1c ] PROTON-853 : add a test that catches the issue from PROTON-154 (and PROTON-850 ) (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 7fa680794b7d78906129216471170dc7d720b156 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7fa6807 ]

          PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850.

          This closes #21

          (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 7fa680794b7d78906129216471170dc7d720b156 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7fa6807 ] PROTON-853 : dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850 . This closes #21 (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1b1c07d1c23d2471b6b85476d29e777cd25fddab in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b1c07d ]

          PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)

          (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1b1c07d1c23d2471b6b85476d29e777cd25fddab in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b1c07d ] PROTON-853 : add a test that catches the issue from PROTON-154 (and PROTON-850 ) (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab)
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 77c1ee076ae4a4bcbec850572deb276ebd0b8c7b in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell
          [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=77c1ee0 ]

          PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850.

          This closes #21

          (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 77c1ee076ae4a4bcbec850572deb276ebd0b8c7b in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=77c1ee0 ] PROTON-853 : dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850 . This closes #21 (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b)

            People

            • Assignee:
              gsim Gordon Sim
              Reporter:
              gsim Gordon Sim
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development