Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-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 C6F1B10DA4 for ; Fri, 15 Nov 2013 16:47:11 +0000 (UTC) Received: (qmail 81316 invoked by uid 500); 15 Nov 2013 16:47:11 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 81295 invoked by uid 500); 15 Nov 2013 16:47:10 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 81287 invoked by uid 99); 15 Nov 2013 16:47:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 16:47:10 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 16:47:05 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAFGkhuA005822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Nov 2013 11:46:43 -0500 Received: from [10.36.116.55] (ovpn-116-55.ams2.redhat.com [10.36.116.55]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAFGkgGL019119 for ; Fri, 15 Nov 2013 11:46:42 -0500 Message-ID: <5286504E.1000204@redhat.com> Date: Fri, 15 Nov 2013 16:48:14 +0000 From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Matt Parsons (USA), Charlie Peters (USA), Paul Hickey (Ireland) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Low throughput with thousands of queues References: <527CC8A0.40205@list-group.com> <52825DA6.1090708@list-group.com> <52863302.8000604@redhat.com> <52864BD4.2050309@list-group.com> In-Reply-To: <52864BD4.2050309@list-group.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Virus-Checked: Checked by ClamAV on apache.org On 11/15/2013 04:29 PM, Flavio Baronti wrote: > Thanks for your suggestion. I tried to implement it, but I did not get > the behaviour I'd like. > If I understood correctly, you suggested to create as many > MessageConsumer instances as topics, and connect every consumer to the > same queue, each time specifying a different binding key. > What happens in this situation is that, for each message which matches > with at least one of the bindings of the queue, one of the consumers is > called, in a round-robin fashion. So the first consumer is called for > the first matching message, the second consumer for the second message, > and so on, with no relationship between the subject of the message and > the intended topic of the consumer. > If this is the expected behaviour, then I'm supposed to implement the > matching logic in the application code, which I was trying to avoid (in > the real application the topics are not always fully-specified, but > often contain # or *). Yes, you are right, I hadn't considered that properly. Sorry! --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org