[
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. 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.
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.
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.
> [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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
