From users-return-30210-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Tue Feb 14 11:57:53 2012 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 EB8A79651 for ; Tue, 14 Feb 2012 11:57:52 +0000 (UTC) Received: (qmail 30122 invoked by uid 500); 14 Feb 2012 11:53:28 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 22824 invoked by uid 500); 14 Feb 2012 11:52:26 -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 4308 invoked by uid 99); 14 Feb 2012 09:06:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Feb 2012 09:06:26 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of herve.barrault@gmail.com designates 209.85.160.171 as permitted sender) Received: from [209.85.160.171] (HELO mail-gy0-f171.google.com) (209.85.160.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Feb 2012 09:06:18 +0000 Received: by ghbf1 with SMTP id f1so3155593ghb.2 for ; Tue, 14 Feb 2012 01:05:58 -0800 (PST) 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; bh=YsrVE3WwvmirRhOAr/oTe+v09H5Q7pNy97ls2pO1Vxo=; b=eridgd8J96d2ZW8+4EBW7BJGRSbSw88ND3lL64yheWdNQzyf3qawHWl/GZy/HZefOT piaQYrKm0LlmmQtLm2XsxwtNEaSLQz+Oezv8ChrAi71Nz0C2wpwmMaijM3p4uAY4efKK dU36dCvGf5JvICjD9kuSZRF0fxqx61Jd4TboQ= MIME-Version: 1.0 Received: by 10.236.72.230 with SMTP id t66mr11855184yhd.98.1329210358142; Tue, 14 Feb 2012 01:05:58 -0800 (PST) Received: by 10.236.175.193 with HTTP; Tue, 14 Feb 2012 01:05:58 -0800 (PST) In-Reply-To: <4F398846.6060009@gmail.com> References: <4F398846.6060009@gmail.com> Date: Tue, 14 Feb 2012 10:05:58 +0100 Message-ID: Subject: Re: Multicast and ActiveMQ From: =?ISO-8859-1?Q?Herv=E9_BARRAULT?= To: users@activemq.apache.org Content-Type: multipart/alternative; boundary=20cf300512c03a987404b8e8e7e3 --20cf300512c03a987404b8e8e7e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi thanks for the answer. I thought using queues (with vm protocol) and with your argument on scalability confirms it. Regards Herv=E9 On Mon, Feb 13, 2012 at 11:01 PM, Matt Pavlovich wrote= : > I recommend using Queues, since Durable Subscriptions can't scale on the > consumer side (JMS spec only allows for one connection per subscriptionId= ). > > Another option would be to use a Camel route to help filter the messages > based on your selector, so you only get messages into queues as needed. > This would help cut down on the wasted messages problem. Also, if you r= un > the Camel route in the same Java VM as ActiveMQ, you can use ActiveMQ's > vm:// transport for super fast processing by the Camel route. > > Producer -> General.Q -> Camel route (content based router) -> QueueA, > QueueB, QueueC > > ActiveMQ does have another feature called Virtual Destinations, but I > don't recommend using them, except in certain situations, and this isn't > one of them. The advantage of the Camel route is that you can start/stop > it without having to start/stop the broker, as well as having more > flexibility available to you in the routing rules. > > Hope this helps! > Matt Pavlovich > > > On 2/13/12 6:58 AM, Herv=E9 BARRAULT wrote: > >> Hi, >> is there no advice to send a message to multiple consumers using activeM= Q >> ? >> >> Regards >> Herv=E9 >> >> On 2/2/12, Herv=E9 BARRAULT> >> wrote: >> >>> Hi, >>> I would multicast messages to different (dynamically determined) >>> consumers. >>> >>> I'm asking myself if it is more efficient to use multiple queues or use= a >>> topic with durable subscription and selectors (I am using persistence). >>> I would say topics reduce the number of persisted messages but i am >>> afraid >>> that one consumer can influence other consumers (if some clients are >>> slower >>> than other). >>> >>> I have already seen that topic could have some problems in case of >>> failover >>> with the subscriptions. >>> >>> What is the best way to accomplish this behavior ? >>> >>> Regards >>> Herv=E9 >>> >>> --20cf300512c03a987404b8e8e7e3--