[
https://issues.apache.org/jira/browse/DISPATCH-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930477#comment-16930477
]
Robbie Gemmell commented on DISPATCH-1421:
------------------------------------------
I think the behaviour you hit is exactly what I commented on [commented
on|https://issues.apache.org/jira/browse/DISPATCH-962?focusedCommentId=16435523&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16435523]
in DISPATCH-962. I didn't know of anything it would cause problems for at the
time so I just noted it then, but you've since come across a case where it did
matter. I do think the router should keep the sent source address detail (which
the broker is authoritative on) in the response attach when it is rejecting the
link, e.g in this case because it doesn't know/allow the target address set by
the producing peer. (Similarly, I think it should keep the sent target address
details when refusing a consuming link, as the receiving peer is authoritative
on that).
> Attaching link to unavailable address sets source address to null in attach
> reply
> ---------------------------------------------------------------------------------
>
> Key: DISPATCH-1421
> URL: https://issues.apache.org/jira/browse/DISPATCH-1421
> Project: Qpid Dispatch
> Issue Type: Bug
> Reporter: Ulf Lilleengen
> Priority: Major
>
> An AMQP client attaches to an address with source address set to 'bar' and
> target address 'remote/foo1' (which the router does not know about):
>
> {code:java}
> [425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar',
> durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null} {code}
>
> As the router does not know about 'remote/foo1', it sets target=null, but
> also source address to 'null' (this is actually null, not the string 'null',
> proton-j is doing the formatting):
> {code:java}
> [425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null}, target=null,
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [425203913:0] <- Detach{handle=0, closed=true,
> error=Error{condition=qd:no-route-to-dest, description='No route to the
> destination node', info=null}} {code}
>
> This can be handled in client code, but the question is if the router should
> keep address='bar' in the replied attach or not.
>
> Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC
> [~robbie])
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
