Return-Path: 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 09ABCDC34 for ; Tue, 30 Oct 2012 12:33:15 +0000 (UTC) Received: (qmail 39739 invoked by uid 500); 30 Oct 2012 12:33:14 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 39604 invoked by uid 500); 30 Oct 2012 12:33:14 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 39593 invoked by uid 99); 30 Oct 2012 12:33:13 -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 12:33:13 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gary.tully@gmail.com designates 74.125.82.171 as permitted sender) Received: from [74.125.82.171] (HELO mail-we0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2012 12:33:07 +0000 Received: by mail-we0-f171.google.com with SMTP id s43so105883wey.2 for ; Tue, 30 Oct 2012 05:32:47 -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=mfjrAqI8K+T2k31WpTKfEmiLsNRJCfhXYHietZaY0hg=; b=Lm5EY0wFhztYgoIkYv7OltxSi3rG8ZC8AsRGOFc3n5um6fjwA8eq2nQ1wocYAwgT3l MEQk9IYqy1XABUlUvMBaku1Uq195RZYofzxaGNraFVc8ZFUPC/qgM7EaoT6yIXhvCZdo lrMhwEGAjIJT92e4QzMwTNdMqiEsHLAP285uv6VaMM3JMCyS3Ogq3NMxBxmkurZchR0B rH+eb6XkirIovSDfD5A3cBLzdeYfPBmsC/xNDp2bXT9KdFWjORKeQhV+efp3frJeB0C2 PeLiREYUiq10DuUQeQL2FX9VEIWXpAeppG0MmKyjqagPNWd5huXQrPmFhTEfJQToEEFN Tvqw== MIME-Version: 1.0 Received: by 10.216.204.19 with SMTP id g19mr16097886weo.189.1351600367448; Tue, 30 Oct 2012 05:32:47 -0700 (PDT) Received: by 10.194.169.3 with HTTP; Tue, 30 Oct 2012 05:32:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Oct 2012 12:32:47 +0000 Message-ID: Subject: Re: Ignoring subscriptions to excluded destinations From: Gary Tully To: users@activemq.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org in your case you need to provide a destinationFilter b/c it is only auto built from 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 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 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 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 >> 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 > >> >wrote: >> >> >> >> > Given: >> >> > >> >> > >> >> > > >> > name="hub" >> >> > duplex="true" >> >> > conduitSubscriptions="false" >> >> > dynamicOnly="false"> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > 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