[
https://issues.apache.org/jira/browse/DISPATCH-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113442#comment-16113442
]
Robbie Gemmell edited comment on DISPATCH-802 at 8/4/17 9:49 AM:
-----------------------------------------------------------------
It feels a little strange that it would ever be possible to consider the
$coordinator pseudo address as a regular address at this point, but even if it
was I don't think a link established to the coordinator target should be
considered to match it, so I'd still expect the link to be refused if such
config wasn't present.
In any case, I'm not sure the above quite works correctly, at least not with
0.8.0 (I haven't tried master, need to get it building), as the router still
accepts the link rather than refuse it, just somewhat unexpectedly replacing
the original 'coordinator target' with a 'regular target' that has no address
set (i.e what we use for the anonymous relay node), and then later detaching it
with an error. It should set the target field entirely null to signal to the
client that it is actually refusing the link.
{noformat}
[99802697:1] ->
Attach{name='qpid-jms:coordinator:ID:672640c9-5477-4ed5-89d9-81c867561a54:1:1',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='null', 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=Coordinator{capabilities=[amqp:local-transactions]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[99802697:1] <-
Attach{name='qpid-jms:coordinator:ID:672640c9-5477-4ed5-89d9-81c867561a54:1:1',
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=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}
[99802697:1] <- Detach{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}}
{noformat}
was (Author: gemmellr):
It feels a little strange that it would ever be possible to consider the
$coordinator pseudo address as a regular address at this point, but even if it
was I don't think a link established to the coordinator target should be
considered to match it, so I'd still expect the link to be refused if such
config wasn't present.
In any case, I'm not sure the above doesn't quite works correctly, at least not
with 0.8.0 (I haven't tried master, need to get it building), as the router
still accepts the link rather than refuse it, just somewhat unexpectedly
replacing the original 'coordinator target' with a 'regular target' that has no
address set (i.e what we use for the anonymous relay node), and then later
detaching it with an error. It should set the target field entirely null to
signal to the client that it is actually refusing the link.
{noformat}
[99802697:1] ->
Attach{name='qpid-jms:coordinator:ID:672640c9-5477-4ed5-89d9-81c867561a54:1:1',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='null', 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=Coordinator{capabilities=[amqp:local-transactions]},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[99802697:1] <-
Attach{name='qpid-jms:coordinator:ID:672640c9-5477-4ed5-89d9-81c867561a54:1:1',
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=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}
[99802697:1] <- Detach{handle=0, closed=true,
error=Error{condition=qd:no-route-to-dest, description='No route to the
destination node', info=null}}
{noformat}
> refuse transaction coordination links if they can't be routed to a coordinator
> ------------------------------------------------------------------------------
>
> Key: DISPATCH-802
> URL: https://issues.apache.org/jira/browse/DISPATCH-802
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Robbie Gemmell
> Assignee: Ganesh Murthy
>
> The router is accepting transaction coordinator links even if the support
> from DISPATCH-195 is not being used to link-route them somewhere that can
> handle coordination. If the router can't link-route to a coordinator, and
> knows it can't coordinate transactions itself, it shouldn't accept the links
> to begin with but rather refuse them so clients know they will never work and
> why.
> Prior to 0.8.0, credit was also given on these links, allowing attempt to
> declare transactions. From 0.8.0 no credit is given since there is no
> receiver, so clients have no way to use the accepted link and no indication
> why.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
