qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PROTON-1849) [c] server behaves incorrectly on duplicate link attach
Date Fri, 18 May 2018 13:14:00 GMT

     [ https://issues.apache.org/jira/browse/PROTON-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alan Conway updated PROTON-1849:
--------------------------------
    Fix Version/s: proton-c-0.23.0

> [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.23.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. An AMQP router
might multiplex traffic originally from multiple connections over a single connection, so
a client reconnecting to a router might create exactly the scenario above, but the duplication
might only be detected after the link-attaches are multiplexed onto a single inter-router
or router-to-broker connection.



--
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


Mime
View raw message