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:41: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.

On the client side, verify that a duplicate link attach will succeed and be propagated to
the remote with a separate handle, allowing the remote to close the original link with STOLEN.
We need to propagate the duplicate attach as the remote may need to be  aware of the link
theft for resource management.

This allows a router network to propagate link theft all the way to a target broker or other
service, which can take appropriate steps to fail-over the link. The theft may originate because
of a client fail-over, but may end up being propgated over a single inter-router or roluter-to-broker
connection so its important that the same-connection and multi-connection cases behave identically.

  was:
--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.


> [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.
> On the client side, verify that a duplicate link attach will succeed and be propagated
to the remote with a separate handle, allowing the remote to close the original link with
STOLEN. We need to propagate the duplicate attach as the remote may need to be  aware of
the link theft for resource management.
> This allows a router network to propagate link theft all the way to a target broker or
other service, which can take appropriate steps to fail-over the link. The theft may originate
because of a client fail-over, but may end up being propgated over a single inter-router or
roluter-to-broker connection so its important that the same-connection and multi-connection
cases behave identically.



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