[ https://issues.apache.org/jira/browse/DISPATCH-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113442#comment-16113442 ]
Robbie Gemmell commented on DISPATCH-802: ----------------------------------------- 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org