You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Todd Baert (JIRA)" <ji...@apache.org> on 2017/12/13 18:30:00 UTC
[jira] [Updated] (ARTEMIS-1556) Cannot Recover AMQP Subscription
Existing On Remote Cluster Member
[ https://issues.apache.org/jira/browse/ARTEMIS-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Baert updated ARTEMIS-1556:
--------------------------------
Description:
Assuming broker1 and broker2 exist in a cluster, if an AMQP Source constituting a shared durable subscription (having capabilities "shared", "global" and "topic") is created on broker1, and attempted to be recovered from a client connected to broker2 (by creating an attach frame with a null source, with desired capabilities "shared", "global" and "topic"), an Amqp.AmqpException is thrown.
In a cluster, shouldn't it be possible to recover subscriptions that exist on another broker? Shouldn't the search for this subscription occur on all cluster members?
I don't believe this is happening. It looks like we just search locally:
See code below from ProtonServerSenderContext (comments are not my own, they are from source):
{code:java}
if (source == null) {
// Attempt to recover a previous subscription happens when a link reattach happens on a
// subscription queue
String clientId = getClientId();
String pubId = sender.getName();
global = hasRemoteDesiredCapability(sender, GLOBAL);
queue = createQueueName(connection.isUseCoreSubscriptionNaming(), clientId, pubId, true, global, false);
QueueQueryResult result = sessionSPI.queueQuery(queue, RoutingType.MULTICAST, false);
multicast = true;
routingTypeToUse = RoutingType.MULTICAST;
// Once confirmed that the address exists we need to return a Source that reflects
// the lifetime policy and capabilities of the new subscription.
if (result.isExists()) {
{code}
was:
Assuming broker1 and broker2 exist in a cluster, if an AMQP Source constituting a shared durable subscription (having capabilities "shared", "global" and "topic") is created on broker1, and attempted to be recovered from a client connected to broker2 (by creating an attach frame with a null source, with desired capabilities "shared", "global" and "topic"), an Amqp.AmqpException is thrown.
In a cluster, shouldn't it be possible to recover subscriptions that exist on another broker? Shouldn't the search for this subscription occur on all cluster members?
I don't believe this is happening. It looks like we just search locally:
See code below from x (comments are not my own, they are from source):
{code:java}
if (source == null) {
// Attempt to recover a previous subscription happens when a link reattach happens on a
// subscription queue
String clientId = getClientId();
String pubId = sender.getName();
global = hasRemoteDesiredCapability(sender, GLOBAL);
queue = createQueueName(connection.isUseCoreSubscriptionNaming(), clientId, pubId, true, global, false);
QueueQueryResult result = sessionSPI.queueQuery(queue, RoutingType.MULTICAST, false);
multicast = true;
routingTypeToUse = RoutingType.MULTICAST;
// Once confirmed that the address exists we need to return a Source that reflects
// the lifetime policy and capabilities of the new subscription.
if (result.isExists()) {
{code}
> Cannot Recover AMQP Subscription Existing On Remote Cluster Member
> -------------------------------------------------------------------
>
> Key: ARTEMIS-1556
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1556
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.4.0
> Environment: Latest broker snapshot running on fedora 26. AMQP .Net Lite client.
> Reporter: Todd Baert
>
> Assuming broker1 and broker2 exist in a cluster, if an AMQP Source constituting a shared durable subscription (having capabilities "shared", "global" and "topic") is created on broker1, and attempted to be recovered from a client connected to broker2 (by creating an attach frame with a null source, with desired capabilities "shared", "global" and "topic"), an Amqp.AmqpException is thrown.
> In a cluster, shouldn't it be possible to recover subscriptions that exist on another broker? Shouldn't the search for this subscription occur on all cluster members?
> I don't believe this is happening. It looks like we just search locally:
> See code below from ProtonServerSenderContext (comments are not my own, they are from source):
> {code:java}
> if (source == null) {
> // Attempt to recover a previous subscription happens when a link reattach happens on a
> // subscription queue
> String clientId = getClientId();
> String pubId = sender.getName();
> global = hasRemoteDesiredCapability(sender, GLOBAL);
> queue = createQueueName(connection.isUseCoreSubscriptionNaming(), clientId, pubId, true, global, false);
> QueueQueryResult result = sessionSPI.queueQuery(queue, RoutingType.MULTICAST, false);
> multicast = true;
> routingTypeToUse = RoutingType.MULTICAST;
> // Once confirmed that the address exists we need to return a Source that reflects
> // the lifetime policy and capabilities of the new subscription.
> if (result.isExists()) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)