[
https://issues.apache.org/jira/browse/DISPATCH-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312605#comment-17312605
]
Ganesh Murthy commented on DISPATCH-2018:
-----------------------------------------
To reproduce this issue, I tried the following -
1. I started a router with the following linkRoute setup
{noformat}
linkRoute {
prefix: examples
dir: out
connection: broker
}
linkRoute {
prefix: examples
dir: in
connection: broker
} {noformat}
2. I started an Artemis broker
3. I ran this python program which simply creates links to the link routed
address
{noformat}
ROUTER_ADDRESS = "amqp://127.0.0.1:5766"
c = BlockingConnection(ROUTER_ADDRESS)
count = 0
while True:
count += 1
print ("Starting " + str(count))
sender = c.create_sender("examples")
sender.close()
if count == 100:
break
{noformat}
While the loop in the above Python program is going on, I shut down the broker
and I end up with the 'No route to destination node' error (which is expected)
with the following trace
{noformat}
Starting 693
[0x557c4922ec30]: AMQP:FRAME:0 -> @attach(18)
[name="80bffd0b-cd54-4d83-8981-573869758d88-examples", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="examples", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0, max-message-size=0]
[0x557c4922ec30]: AMQP:FRAME:0 <- @attach(18)
[name="80bffd0b-cd54-4d83-8981-573869758d88-examples", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, initial-delivery-count=0,
max-message-size=0]
[0x557c4922ec30]: AMQP:FRAME:0 <- @detach(22) [handle=0, closed=true,
error=@error(29) [condition=:"qd:no-route-to-dest", description="No route to
the destination node"]]
{noformat}
I always see your Case #3 happening but I never see your Case 1 (router not
responding to the attach at all) or Case 2 (populated target, having address =
null) happening
Do you have a reproducer that I can use to reproduce Cases 1 and 2 ?
> 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
