You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2018/06/26 14:55:00 UTC
[jira] [Reopened] (PROTON-1849) [c] server behaves incorrectly on
duplicate link attach
[ https://issues.apache.org/jira/browse/PROTON-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell reopened PROTON-1849:
------------------------------------
> [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
>
> --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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org