[ https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225099#comment-16225099 ]
Lorenz Quack commented on QPID-7994: ------------------------------------ A couple of points: * Regarding the existing behaviour: The broker *does* look for the link. But the link defined by the triplet (remote-container-id, role, name) cannot be found because the remote-container-id does not match. Since it cannot recover the link the broker decides to reject the link. * I disagree with what you wrote the broker should do. I think that would break compliance with AMQP core spec which clearly states that a link is defined by the triplet (remote-container-id, role, name). And furthermore, I don't think that is the behaviour QPIDJMS-220 suggests. Nowhere does it state that a link from a different remote-container-id should be recovered. * I think the broker is correct in not recovering a link not matching the triplet. However, it clearly does not do the right thing when unsubscribing a global durable share subscription. However instead of putting this responsibility on the link recovery path I would suggest to put the responsibility on either {{SendingLinkEndpoint#detach}} or somewhere on the {{AbstractVirtualHost#removeSubscriptionQueue}} path. > [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' > on attaching of unsubscribe links for global durable shared subscriptions > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: QPID-7994 > URL: https://issues.apache.org/jira/browse/QPID-7994 > Project: Qpid > Issue Type: Bug > Reporter: Alex Rudyy > > As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220] > {quote} > During unsubscribe, if a ClientID is set on the connection, a link named with > the subscription name would be used to perform a 'null source lookup' for the > subscription, as it is already for the existing non-shared durable > subscriptions (see earlier for behaviour outline). If a ClientID is not set, > the "|global" suffix will be added as shown previously.. > {quote} > The current broker behaviour is not compliment with QPIDJMS-220. The broker > create a new link instead of looking for existing link having name > {{<subscription-name>|global}} as suggested by QPIDJMS-220. For the new link, > the local source is null. As result, 'not=found' error is reported. > The broker should try to find an existing link in the link registry using > link name only rather than name and a container ID as it does now. If link > with given name is found, it should be used to recover the source. The broker > should perform the search by link name only if {{SHARED}} capability is > requested either on connection or attach itself as suggested by QPIDJMS-220: > {quote} > Additionally, while using connections that dont have a ClientID set, i.e > using global shared susbcriptions, the link will have "shared" and "global" > desired capabilities added as hints to the server that this is an attempt to > attach to a 'global' shared subscription of the appropriate name derived from > the link, aiding the server should no link with this name be known by it for > the particular client container-id currently in use. > {quote} -- 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