You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2019/10/03 19:31:07 UTC

[jira] [Commented] (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=16943846#comment-16943846 ] 

ASF subversion and git services commented on DISPATCH-1421:
-----------------------------------------------------------

Commit 15db9bf50e12f003eff97ab0c4ca6ca952510fb8 in qpid-dispatch's branch refs/heads/master from Gordon Sim
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=15db9bf ]

DISPATCH-1421: copy terminus for which peer is authoritative when refusing link


> 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
>            Assignee: Ganesh Murthy
>            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.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org