Return-Path: 
 <users-return-32339-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org>
X-Original-To: apmail-activemq-users-archive@www.apache.org
Delivered-To: apmail-activemq-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 10959D267
	for <apmail-activemq-users-archive@www.apache.org>;
 Tue, 30 Oct 2012 14:39:41 +0000 (UTC)
Received: (qmail 91794 invoked by uid 500); 30 Oct 2012 14:39:40 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 91694 invoked by uid 500); 30 Oct 2012 14:39:40 -0000
Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@activemq.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@activemq.apache.org>
List-Post: <mailto:users@activemq.apache.org>
List-Id: <users.activemq.apache.org>
Reply-To: users@activemq.apache.org
Delivered-To: mailing list users@activemq.apache.org
Received: (qmail 91668 invoked by uid 99); 30 Oct 2012 14:39:39 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2012 14:39:39 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of james.mk.green@gmail.com
 designates 209.85.160.43 as permitted sender)
Received: from [209.85.160.43] (HELO mail-pb0-f43.google.com) (209.85.160.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2012 14:39:33 +0000
Received: by mail-pb0-f43.google.com with SMTP id jt11so222642pbb.2
        for <users@activemq.apache.org>; Tue, 30 Oct 2012 07:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=N1gEl9KcYiBuTjHLy759y1Np8iUFamcWASrW4YCcqRg=;
        b=jp/1nQPJkN8HnpFJFQV2Mi+OUxryjEk4vme6oviEMWFT5J+CDvFDh6c7kAB+AqbEd8
         6fOC6n+1mnjJO3W3jlOqeCWa9bJT+Tw5oSqmnpln7NhH1fTrt9AUfwV8kNwWT8yqXFcC
         7wAu7/MtyAq29Ycd4ynkKAYgjjO76YhWgSdm8kZ3juT/jiwyrvCBncUkpGgHaqI829pA
         Nq+N0+hhr7T3siOUAGJxZXaS6Jc/AgdHGYannafghf0UCNvc5KZGHdjo8RZLyiom65EM
         WJGndnO1bphJogJf11r4YK6T/glHgApzHAwn5MwNKpkyfdUgOgSdILarkwjWX9kZLu4e
         bbCA==
MIME-Version: 1.0
Received: by 10.68.213.33 with SMTP id np1mr102612244pbc.64.1351607952111;
 Tue, 30 Oct 2012 07:39:12 -0700 (PDT)
Received: by 10.68.226.33 with HTTP; Tue, 30 Oct 2012 07:39:12 -0700 (PDT)
In-Reply-To: 
 <CAH+vQmP7=VgThMhJfZicb=WSAXDYDMgF_xP0t5o3ztATzc+o-Q@mail.gmail.com>
References: 
 <CAMH6+azZYhT93XrY+eqH-L5B065LOWf=Z26LEisL65j_02G-xA@mail.gmail.com>
	<CAKS7T5MY22vqB11rLSb6JLvwOfW4R2wE8HM0wFdLmksXjGHuRg@mail.gmail.com>
	<CAMH6+azsejiNB8zadd5_VYo0U_9Y-42Uyg+7YC6To7zt+k5Zxw@mail.gmail.com>
	<CAH+vQmN2dfi+cGMynZgH7fa1KeeGE=x0HLObxvShyL5K=A9zbw@mail.gmail.com>
	<CAMH6+az56e_QqHBdTYByHXOefMOE5+yghzYW_uiTUj2qmBxRtA@mail.gmail.com>
	<CAH+vQmOtiR2da0+LUd8Qu_xSmWjezVc9HB6gqfee6LehH9d6Xw@mail.gmail.com>
	<CAMH6+az4uLj1sz7-vNSevCRLgu3VeCqxLYS=NT=EiJA19T+vNA@mail.gmail.com>
	<CAH+vQmP7=VgThMhJfZicb=WSAXDYDMgF_xP0t5o3ztATzc+o-Q@mail.gmail.com>
Date: Tue, 30 Oct 2012 14:39:12 +0000
Message-ID: 
 <CAMH6+axYp36EAgWgBL+56EtthMXXr_-08bK-Cgy5yq3xOjCTOg@mail.gmail.com>
Subject: Re: Ignoring subscriptions to excluded destinations
From: James Green <james.mk.green@gmail.com>
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=e89a8ff1c12edc78df04cd47bf06
X-Virus-Checked: Checked by ClamAV on apache.org

--e89a8ff1c12edc78df04cd47bf06
Content-Type: text/plain; charset=ISO-8859-1

Gary,

On our test cluster one of our spokes has been configured thus:

        <networkConnectors>
           <networkConnector uri="static://(tcp://10.0.0.117:61616)"
               name="plenty-hub-01"
               duplex="true"
               conduitSubscriptions="false"
               dynamicOnly="false">
               <excludedDestinations>
               </excludedDestinations>
               <dynamicallyIncludedDestinations>
                        <queue physicalName="account_events"/>
                        <queue physicalName="accounts.ack"/>
               </dynamicallyIncludedDestinations>
           </networkConnector>
       </networkConnectors>

.117 is our test hub.

Against the spoke we subscribed to the Outbound.Account.200002 queue, and
.117 logged the consumer and that it had to ignore it.

We even restarted the hub's AMQ instance and deleted the advisory topic on
the hub that had been created. Still, we get traffic.

I am now at a loss to explain this traffic. Is there something else we must
do?

Thanks,

James

On 30 October 2012 14:22, Gary Tully <gary.tully@gmail.com> wrote:

> there are two different filters involved.
>
> The bridge gets notification of demand on a destination, ie:
> consumers, using an advisory consumer.
> To reduce the advisory traffic, the set of matching advisory
> destinations subscribed to can be filtered. Using the
> destinationFilter property or generated from the dynamically included
> list.
>
> If the advisory consumer does not listen to specific destinations then
> it won't ever get notification of them and won't ever have to filter
> at the bridge level.
>
> The list of exclusions only works at the bridge level, where it
> processes advisory messages, so is independent of the
> destinationFilter.
>
> So for your whitelist, just deal with application destinations, the
> corresponding advisory destinations will be subscribed to
> automatically.
>
>
> On 30 October 2012 12:40, James Green <james.mk.green@gmail.com> wrote:
> > http://activemq.apache.org/networks-of-brokers.html states for
> > dynamicallyIncludedDestinations that "destinations that match this list *
> > will* be forwarded across the network *n.b.* an empty list means all
> > destinations not in the exluded list will be forwarded".
> >
> > This reads to me that, given an empty dynamic list and a set of
> exclusions,
> > only those exclusions will be totally filtered. That's not the case at
> all
> > (evidently).
> >
> > We will try to build a list of dynamic inclusions (a whitelist instead
> of a
> > blacklist). Do we need to include topics for advisories on the queues or
> > just the queues themselves? Otherwise presumably the consumer
> subscription
> > information on queues/topics sent from hub to spoke won't get notices on
> > the hub and thus the hub will not send the messages to the hub on demand?
> >
> > Thanks,
> > James
> >
> > On 30 October 2012 12:32, Gary Tully <gary.tully@gmail.com> wrote:
> >
> >> in your case you need to provide a destinationFilter b/c it is only
> >> auto built from <dynamicalyIncludedDestinations> not excluded
> >> destinations.
> >>
> >> Do you know up front what you want to bridge or just what you want to
> >> ignore?
> >>
> >> A the moment, afaik,  we don't have a way of providing a negative
> >> filter which seems to be what you want.
> >>
> >> On 30 October 2012 12:08, James Green <james.mk.green@gmail.com> wrote:
> >> > Gary,
> >> >
> >> > I think you're saying that subscription advisories for excluded
> >> > destinations should be suppressed.
> >> >
> >> > On the hub we're seeing advisories for queues on that spoke. Is there
> >> > therefore a bug?
> >> >
> >> > James
> >> >
> >> > On 30 October 2012 11:58, Gary Tully <gary.tully@gmail.com> wrote:
> >> >
> >> >> the destinationFilter does the job of narrowing the list of
> >> >> interesting consumers by limiting the advisory consumer to a subset
> of
> >> >> destinations.
> >> >> This is auto generated if it is not configured from 5.6.0, but needs
> >> >> both ends of the networkconnector to be => 5.6
> >> >>
> >> >> Have a peek at:
> >> >> https://issues.apache.org/jira/browse/AMQ-3384
> >> >>
> >> >>
> >> >> On 30 October 2012 09:10, James Green <james.mk.green@gmail.com>
> wrote:
> >> >> > Part of my intention of declaring excluded destinations was to
> reduce
> >> the
> >> >> > amount of traffic over the ADSL line that exists between hub and
> the
> >> >> spokes.
> >> >> >
> >> >> > However, despite the instruction to ban messaging on these
> >> destinations,
> >> >> > the amount of traffic and instructions that the hub receives has
> not
> >> >> > changed.
> >> >> >
> >> >> > The documentation, in my opinion, gives the impression that
> excluded
> >> >> > destinations is to segregate the network; actually it only
> performs a
> >> >> very
> >> >> > thin segregation. People wanting to reduce the bandwidth between
> nodes
> >> >> will
> >> >> > use this and may be rather disappointed by the results...
> >> >> >
> >> >> > James
> >> >> >
> >> >> > On 29 October 2012 22:23, Christian Posta <
> christian.posta@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >> >
> >> >> >> > I was expecting to see no traffic of any kind on our hub
> concerning
> >> >> >> > Outbound.Account.>, yet sub requests are still flooding in.
> >> >> >>
> >> >> >> Can you explain more what you mean? Do you see subs being created
> for
> >> >> that
> >> >> >> dest on the networked brokers?
> >> >> >>
> >> >> >> If what you mean is you're seeing the logs below, that's as
> intended.
> >> >> When
> >> >> >> a bridge is established, it will listen to the remote broker's
> >> consumer
> >> >> >> advisory messages (it listens to all of them, they are not
> filtered).
> >> >> If it
> >> >> >> sees a consumerInfo come in for a destination that is excluded, it
> >> will
> >> >> >> just ignore it and log the message you see below. This is by
> design,
> >> at
> >> >> the
> >> >> >> moment.
> >> >> >>
> >> >> >> On Mon, Oct 29, 2012 at 5:59 AM, James Green <
> >> james.mk.green@gmail.com
> >> >> >> >wrote:
> >> >> >>
> >> >> >> > Given:
> >> >> >> >
> >> >> >> >         <networkConnectors>
> >> >> >> >             <networkConnector uri="static://(ssl://hub:61617)"
> >> >> >> >                 name="hub"
> >> >> >> >                 duplex="true"
> >> >> >> >                 conduitSubscriptions="false"
> >> >> >> >                 dynamicOnly="false">
> >> >> >> >                 <excludedDestinations>
> >> >> >> >                     <queue physicalName="Outbound.Account.>"/>
> >> >> >> >                 </excludedDestinations>
> >> >> >> >                 <staticallyIncludedDestinations>
> >> >> >> >                 </staticallyIncludedDestinations>
> >> >> >> >             </networkConnector>
> >> >> >> >         </networkConnectors>
> >> >> >> >
> >> >> >> > On "hub" I see:
> >> >> >> >
> >> >> >> > 2012-10-29 12:44:34,722 | DEBUG | hub Ignoring sub from zorin,
> >> >> >> destination
> >> >> >> > queue://Outbound.Account.20481 is not permiited :ConsumerInfo
> >> >> {commandId
> >> >> >> =
> >> >> >> > 5, responseRequired = false, consumerId =
> >> >> >> > ID:quarrel-40451-1351260922652-4:760216:-1:2, destination =
> >> >> >> > queue://Outbound.Account.20481, prefetchSize = 1,
> >> >> >> > maximumPendingMessageLimit = 0, browser = false, dispatchAsync =
> >> true,
> >> >> >> > selector = MJStage = 'Dispatch', subscriptionName = null,
> noLocal =
> >> >> >> false,
> >> >> >> > exclusive = false, retroactive = false, priority = 0,
> brokerPath =
> >> >> null,
> >> >> >> > optimizedAcknowledge = false, noRangeAcks = false,
> >> >> additionalPredicate =
> >> >> >> > null} |
> org.apache.activemq.network.DemandForwardingBridgeSupport |
> >> >> >> > ActiveMQ Transport: ssl:///n.n.n.n:32831
> >> >> >> >
> >> >> >> > I was expecting to see no traffic of any kind on our hub
> concerning
> >> >> >> > Outbound.Account.>, yet sub requests are still flooding in.
> >> >> >> >
> >> >> >> > Is this normal? Can I get my desired result?
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> >
> >> >> >> > James
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> *Christian Posta*
> >> >> >> http://www.christianposta.com/blog
> >> >> >> twitter: @christianposta
> >> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> http://redhat.com
> >> >> http://blog.garytully.com
> >> >>
> >>
> >>
> >>
> >> --
> >> http://redhat.com
> >> http://blog.garytully.com
> >>
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>

--e89a8ff1c12edc78df04cd47bf06--