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 3D4831107A for ; Fri, 29 Aug 2014 22:11:26 +0000 (UTC) Received: (qmail 97136 invoked by uid 500); 29 Aug 2014 22:11:21 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 97097 invoked by uid 500); 29 Aug 2014 22:11:21 -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 97080 invoked by uid 99); 29 Aug 2014 22:11:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 22:11:20 +0000 X-ASF-Spam-Status: No, hits=2.3 required=5.0 tests=SPF_SOFTFAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of xiaodan.wang@salesforce.com does not designate 216.139.236.26 as permitted sender) Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Aug 2014 22:11:16 +0000 Received: from jim.nabble.com ([192.168.236.80]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XNUNi-0003wx-Ef for users@qpid.apache.org; Fri, 29 Aug 2014 15:10:54 -0700 Date: Fri, 29 Aug 2014 15:10:54 -0700 (PDT) From: "xiaodan.wang" To: users@qpid.apache.org Message-ID: <1409350254445-7612825.post@n2.nabble.com> In-Reply-To: References: <1409099599208-7612615.post@n2.nabble.com> <1409174210942-7612668.post@n2.nabble.com> Subject: Re: 1 Queue with 2 Consumers - turn off pre-fetching? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org rgodfrey wrote > Is the destination that the message was sent to / the consumer that was > created to receive the message a Queue or a Topic? > > I did a little test myself (sending to a queue object, receiving from a > queue object) and the object that I got back from getJMSDestination() was > a > queue (and not a Topic as you seem to be getting)... however I did notice > that the queue seemed to be in binding URL and not Address format - so I > will try to fix that at least. Hi Rob, some additional context on the behavior I'm seeing. The queues were originally created on a v0.16 broker using AMQP 0-10 and are addressed as follow: 'Q1'/None; { 'create': 'always', 'node': { 'durable': 'true', 'type': 'queue', 'x-declare': { 'arguments': { 'x-qpid-priorities': 10 } } } } Using an AMQP 0-10 client, I'm seeing the following: a) When message is enqueued type is: AMQAnyDestination b) When we create the consumer: AMQAnyDestination c) when we call getJMSDestination after message is received: AMQAnyDestination Using AMQP 0-91 client (jvm argument -Dqpid.amqp.version=0-91 with no other code changes): a) When message is enqueued type is: AMQAnyDestination b) When we create the consumer: AMQAnyDestination c) when we call getJMSDestination after message is received: *AMQTopic* topic://<>/Q1/?routingkey='Q1'&exclusive='true'&autodelete='true' I did notice a slight difference in the destination string when message is enqueued through a AMQP 0-91 client: 'Q1'/None; { 'create': 'always', 'node': { 'durable': 'true', 'type': 'queue', 'x-declare': { 'arguments': { *'no-local': False,* 'x-qpid-priorities': 10 } } } } I think the "*'no-local': False,*" parameter has no impact on our application since we use separate connections to enqueue messages vs receiving messages. Now that I think about it, I'm seeing another issue that might be related to this (i.e. message received in AMQP 0-91 returns a destination of type AMQTopic). With AMQP 0-10, we were able to repeatedly call consumer.receive in order to fetch additional (>1) messages from the queue. Using AMQP 0-91, consumer.receive only returns a single message, subsequent invocations time out (even though messages are available). Only if we committed on the session after each receive were we able to fetch all messages from the queue. -- View this message in context: http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-tp6934582p7612825.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org