From users-return-28041-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Thu Jun 30 11:09:55 2011 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 85667605E for ; Thu, 30 Jun 2011 11:09:55 +0000 (UTC) Received: (qmail 20427 invoked by uid 500); 30 Jun 2011 11:09:54 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 19984 invoked by uid 500); 30 Jun 2011 11:09:50 -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 19956 invoked by uid 99); 30 Jun 2011 11:09:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2011 11:09:49 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com designates 209.85.216.43 as permitted sender) Received: from [209.85.216.43] (HELO mail-qw0-f43.google.com) (209.85.216.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2011 11:09:44 +0000 Received: by qwf6 with SMTP id 6so1320270qwf.2 for ; Thu, 30 Jun 2011 04:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=JTRHPLOSoIT6S5t22II1u0vjtnoARkNyHbSP4IAd3ys=; b=GT+N3S0ZFbSx2xkAgQh0DtIBmba+zkU5bM41wrYvRrzNnHCyc9dYo5VTVwY7aYBxrb Ki1ziTq4+yIap/ZcbrP/s/3urgAeGZQxrTQ8ipYnDBUYkrLpVlMTqtFgX6eG6i0xGGFw APdOODBq8Du6p+VxGFYYtmE4qizaaxVgOURKQ= MIME-Version: 1.0 Received: by 10.229.247.203 with SMTP id md11mr1340989qcb.268.1309432163568; Thu, 30 Jun 2011 04:09:23 -0700 (PDT) Received: by 10.229.211.207 with HTTP; Thu, 30 Jun 2011 04:09:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 12:09:23 +0100 Message-ID: Subject: Re: Saving bandwith in a network-of-brokers with lots of brokers via WAN From: Gary Tully To: users@activemq.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CACHE_CONSUMER will help, but also setting the networkConnector attribute destinationFilter and if you don't want to bridge temp destinations set bridgeTempDestinations=3D"false" It defaults to ">" so the network connector gets consumer advisories for all destinations, but ideally it should be correlated (or automatically determined) with the set of dynamicallyIncludedDestinations. The syntax for 'destinationFilter' is a little odd bc the value is prefexed with "ActiveMQ.Advisory.Consumer." when it is applied. I have created an enhancement to make this automatic. https://issues.apache.org/jira/browse/AMQ-3384 The other alternative is to disable advisories and configure an entirely static network topology using static includes, but messages will flow independent of demand in that scenario. On 30 June 2011 11:30, Martin C. wrote: > Hi, > > we plan a setup with lots of remote sites, each of them having their > own broker which are then connected via a network-of-brokers via a > duplex connector. We'd like to use dynamicallyIncludedDestinations, > but even in our small test installation we already see huge amounts of > advisory messages. This is expected, as I understand that this is used > for handling the dynamic includes. As we are using Spring's > MessageListenerContainer, with a a lot of dynamic scaling to the > current on-site load, a lot of Advisories are generated and already > dominate the network traffic by far. > > Are there any options we can set in order to reduce the number of > advisories? We are already using conduitSubscriptions=3Dtrue so there'd > be no need to go over-the-wire as long as there is at least a single > consumer. I tried to exclude with > =A0" /> > but this didn't result in any reduction of the messages sent via the > network bridges. > > We are now evaluating if we can use CACHE_CONSUMER with the message > listener container in order to reduce the number of subscription > changes, but still there is a lot of noise due to number of consumers > scaling up/down. > > Thanks for any hint! > > Best regards, > Martin > --=20 http://fusesource.com http://blog.garytully.com