[
https://issues.apache.org/jira/browse/DISPATCH-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313073#comment-17313073
]
Robbie Gemmell edited comment on DISPATCH-2018 at 4/1/21, 10:52 AM:
--------------------------------------------------------------------
I dont personally have a reproducer. My log snippets were out of a separate
user report of a client issue, where I spotted the router behaviours in the
protocol trace logs and it was the 'case 2' behaviour that caused the client to
allow the application/itself into a state that then gave opportunity to hit the
clients own bug in handling the scenario (QPIDJMS-529).
I'll point you to the report elsewhere, but I'd say the main difference looks
to be repetition and timing. The user scenario looked to open+use+closes a
sender periodically over time, and repeatedly down the link routed broker while
this is ongoing. It also has link routed consumer to consume the messages it
sends.
was (Author: gemmellr):
I dont personally have a reproducer. My log snippets were out of a separate
user report of a client issue, where I spotted the router behaviours in the
protocol trace logs and it was the 'case 2' behaviour that caused the client to
allow the application/itself into a state that then gave opportunity to hit the
clients own bug in handling the scenario (QPIDJMS-529).
I'll point you to the report elsewhere, but I'd say the main difference looks
to be repetition and timing. The user scenario looked to open+use+closes a
sender periodically over time, and repeatedly down the link routed broker while
this is ongoing. It also has link routed consumer to consumer the messages it
sends.
> 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 one 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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
