[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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[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=16932145#comment-16932145
]
Ulf Lilleengen commented on DISPATCH-1421:
--
[~ganeshmurthy] for EnMasse, the consequence is that ActiveMQ Artemis does not
handle this situation well and will cause spurious log errors. See
https://issues.apache.org/jira/browse/ARTEMIS-2488 for more details on that.
There is a proposed PR to fix the Artemis handling, but it seemed like a
strange behavior on the router side also.
> 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.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[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=16931798#comment-16931798
]
Ganesh Murthy commented on DISPATCH-1421:
-
[~lulf] What is the user facing consequence of this ?
> 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
[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=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
