[
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: [email protected]
For additional commands, e-mail: [email protected]
