You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (Jira)" <ji...@apache.org> on 2019/09/16 12:07:00 UTC

[jira] [Comment Edited] (DISPATCH-1421) Attaching link to unavailable address sets source address to null in attach reply

    [ https://issues.apache.org/jira/browse/DISPATCH-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930477#comment-16930477 ] 

Robbie Gemmell edited comment on DISPATCH-1421 at 9/16/19 12:06 PM:
--------------------------------------------------------------------

I think the behaviour you hit is exactly what I [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).


was (Author: gemmellr):
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org