qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lorenz Quack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
Date Mon, 30 Oct 2017 15:13:00 GMT

    [ 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}}

> [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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message