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:13:00 GMT

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

Alan Conway updated PROTON-1849:
--------------------------------
    Description: 
--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.

  was:
There is a disabled test to reproduce this problem, see test_duplicate_link_client() in

[https://github.com/alanconway/qpid-proton/blob/master/c/tests/connection_driver.c#L498]

pni_process does all pending link opens before all pending link closes, it does not respect
the order of individual open/close calls in the code. This doesn't cause a problem for distinct
links but if a link of the same name is opened/closed/reopened very quickly it can cause a
problem:

For example if l1 and l2 are both pn_links with name "x" then this sequence:
{code:java}
open(l1); close(l1); open(l2){code}
generates this illegal protocol sequence:
{code:java}
attach("x"); attach("x"); detach(0) // 0 is the handle assigned to "x"{code}
instead of the intended legal sequence:
{code:java}
attach("x"); detach(0); attach("x") // detach(0) detaches the first "x" so second "x" is allowed{code}
NOTE: This applies to all endpoints, not just links but since connections and sessions don't
have client-assignable names that can clash, the problem only shows up for links and only
if the detach/attach for the same name is processed in the same transport batch. This is unlikely
in practice and was discovered only because of investigation of PROTON-1832.


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