[
https://issues.apache.org/jira/browse/DISPATCH-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated DISPATCH-2018:
-------------------------------------
Description:
In case of a router doing link routing to a broker, which goes away during an
error handling test, the router can then need to refuse new links and/or kill
existing links as it has nowhere to route them. That is all to be expected.
When failing to attach some sender links though, it was observed the router in
once case did not response to a clients attach at all, and in a second case
incorrectly sent a response attach with a populated target, having address =
null, followed by a detach with error (which looks to lead to some unexpected
client behaviour as it was mislead into thinking the producer actually opened,
likely exposing a separate client issue).
The attach in the second case should have had target=null, rather than a null
address, to indicate that this was a link refusal and the detach with error
would follow:
{noformat}
[1475580346:1] ->
Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[1475580346:1] <-
Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1475580346:1] <- Detach\{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}}
{noformat}
In a third related instant earlier in the testing, the router did actually do
the correct thing while returning a [different] error, ommitting the attach
target entirely as is directed by the protocol spec:
{noformat}
[851826403:1] ->
Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[851826403:1] <-
Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null}, target=null,
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[851826403:1] <- Detach\{handle=0, closed=true,
error=Error{condition=qd:routed-link-lost, description='Connectivity to the
peer container was lost', info=null}}
{noformat}
was:
In case of a router doing link routing to a broker, which goes away during an
error handling test, the router can then need to refuse new links and/or kill
existing links as it has nowhere to route them. That is all to be expected.
When failing to attach some sender links though, it was observed the router in
once case did not response to a clients attach at all, and in a second case
incorrectly sent a response attach with a populated target, having address =
null, followed by a detach with error (which looks to lead to some unexpected
client behaviour as it was mislead into thinking the producer actually opened,
likely exposing a separate client issue).
The attach in the second case should have had target=null, rather than a null
address, to indicate that this was a link refusal and the detach with error
would follow:
{noformat}
[1475580346:1] ->
Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[1475580346:1] <-
Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1475580346:1] <- Detach\{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}}
{noformat}
In a third related instant earlier in the testing, the router did actually do
the correct thing while returning a [different] error, ommitting the attach
target entirely as is directed by the protocol spec:
{noformat}
[851826403:1] ->
Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null},
target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=[DELAYED_DELIVERY], properties=null}
[851826403:1] <-
Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=null}, target=null,
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[851826403:1] <- Detach\{handle=0, closed=true,
error=Error{condition=qd:routed-link-lost, description='Connectivity to the
peer container was lost', info=null}}
> Improper handling of link refusal when destination peer for link-routing goes
> away
> ----------------------------------------------------------------------------------
>
> Key: DISPATCH-2018
> URL: https://issues.apache.org/jira/browse/DISPATCH-2018
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 1.14.0
> Reporter: Robbie Gemmell
> Priority: Major
>
> In case of a router doing link routing to a broker, which goes away during an
> error handling test, the router can then need to refuse new links and/or kill
> existing links as it has nowhere to route them. That is all to be expected.
> When failing to attach some sender links though, it was observed the router
> in once case did not response to a clients attach at all, and in a second
> case incorrectly sent a response attach with a populated target, having
> address = null, followed by a detach with error (which looks to lead to some
> unexpected client behaviour as it was mislead into thinking the producer
> actually opened, likely exposing a separate client issue).
> The attach in the second case should have had target=null, rather than a null
> address, to indicate that this was a link refusal and the detach with error
> would follow:
> {noformat}
> [1475580346:1] ->
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [1475580346:1] <-
> Attach\{name='qpid-jms:sender:ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1:destination',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='ID:cc949561-56bc-44f7-8d96-74f8a8d49988:521:8:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target\{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1475580346:1] <- Detach\{handle=0, closed=true,
> error=Error{condition=qd:no-route-to-dest, description='No route to the
> destination node', info=null}}
> {noformat}
> In a third related instant earlier in the testing, the router did actually do
> the correct thing while returning a [different] error, ommitting the attach
> target entirely as is directed by the protocol spec:
> {noformat}
> [851826403:1] ->
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target\{address='destination', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [851826403:1] <-
> Attach\{name='qpid-jms:sender:ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1:destination',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='ID:d070acab-905f-45a7-b663-14d35547ab3e:3:25:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null}, target=null,
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [851826403:1] <- Detach\{handle=0, closed=true,
> error=Error{condition=qd:routed-link-lost, description='Connectivity to the
> peer container was lost', info=null}}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
