[ https://issues.apache.org/jira/browse/PROTON-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway closed PROTON-1849. ------------------------------- Resolution: Duplicate > [c] server behaves incorrectly on duplicate link attach > ------------------------------------------------------- > > Key: PROTON-1849 > URL: https://issues.apache.org/jira/browse/PROTON-1849 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Affects Versions: proton-c-0.22.0 > Reporter: Alan Conway > Assignee: Alan Conway > Priority: Minor > Fix For: proton-c-0.24.0 > > > --The fix for > PROTON-1832: [c] reject duplicate link attach with connection error. > Is incorrect. It raises a transport eror on duplicate link names. That is > better than crashing but the AMQP spec says: > > {quote}2.6.1 Naming A Link > [snip] > A link's name uniquely identifies the link from the container of the source > to the container of the target node, i.e., if the container of the source > node is A, and the container of the target node is B, the link can be > globally identified by the (ordered) tuple _(A,B,<name>)_. Consequently, a > link can only be active in one connection at a time. If an attempt is made to > attach the link subsequently when it is not suspended, then the link can be > 'stolen', i.e., the second attach succeeds and the first attach MUST then be > closed with a link error of > [stolen|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#choice-link-error-stolen]. > This behavior ensures that in the event of a connection failure occurring > and being noticed by one party, that re-establishment has the desired effect. > {quote} > The spec is anticipating duplicate names being used on *different* > connections during reconnect but we should treat duplicates on the same > connection the same way. In particular proton should dispatch the events to > close the stolen link *before* the events that open the new link. > On the client side, a duplicate link attach will cause the original link to > be closed with a STOLEN error, then open the new link. The events and > protocol frames will show the close/STOLEN first, then the open. > This is more consistent with the spec, and more forgiving than closing the > connection with an error. It means intermediaries that just forward link > traffic will do the right thing automatically on an upstream reconnect (close > and re-open the downstream link) even if they don't locally check for link > name duplication. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org