[
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: [email protected]
For additional commands, e-mail: [email protected]
