Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4DF0A267.5020209@redhat.com>
Date: Thu, 09 Jun 2011 11:37:27 +0100
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Brendan Lane
 (Ireland), Matt Parsons (USA), Charlie Peters (USA)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b1
 Thunderbird/3.0.10
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Recommended API for Python?
References: <4DE921C0.2000509@princeton.com> <4DE92EB9.6050806@redhat.com>
 <4DEEBBFA.30708@princeton.com> <4DEF7263.7020505@redhat.com>
 <4DEF9139.9030202@princeton.com>
In-Reply-To: <4DEF9139.9030202@princeton.com>
Content-Type: multipart/mixed;
 boundary="------------070008090102010507080905"

--------------070008090102010507080905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 06/08/2011 04:11 PM, Anthony Foglia wrote:
> On 06/08/2011 09:00 AM, Carl Trieloff wrote:
>> async transfer is the largest impact, not acknowledgement.
>
> How do I do that? I'm already setting the capacity of the receiver to
> 1000, which we found was the best for the Python code.

I believe the issue is in the way you are doing this for the swigged 
client. At present you need to use the setCapacity() method to set the 
capacity rather than setting it as an attribute.

With that change in place I see the rcv_rate for the swig api jump from 
~1,300 to ~19,000 for 20,000 msgs.

I would also echo Ted's comments, that the messaging API is really what 
we recommend, and that the swigged version when completed would be a 
drop in replacement for that (avoiding annoyances like the above).

[Just for clarity: synchronous acknowledgement per message would have a 
pretty similar effect to synchronous transfer (round trip forced 
per-message). Obviously if the acknowledgements are batched then the 
roundtrip is less frequent and therefore has less impact].

>> On 06/07/2011 08:02 PM, Anthony Foglia wrote:
>>> I've attached the code I'm using in a tarball, in case people have any
>>> suggestions.
>>
>>
>> tar's don't attach to the list, use a JIRA.

FWIW the tars came through on the original mail fine for me....

>
> Okay. I opened a JIRA task and attached my code (plus two of the outputs).
>
> https://issues.apache.org/jira/browse/QPID-3297
>


--------------070008090102010507080905
Content-Type: text/x-patch;
 name="capacity.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="capacity.patch"

diff -up ./timing_consumer.messaging.py.orig ./timing_consumer.messaging.py
--- ./timing_consumer.messaging.py.orig	2011-06-09 11:36:20.578727759 +0100
+++ ./timing_consumer.messaging.py	2011-06-09 11:18:56.489727876 +0100
@@ -78,8 +78,8 @@ def read_messages_swig(connection, queue
   timeout = 10
 
   receiver = session.createReceiver(queue)
-  receiver.capacity = 1000
-  print "Receiver capacity =",receiver.capacity
+  receiver.setCapacity(1000)
+  print "Receiver capacity =",receiver.getCapacity()
   
   while True :
     try :


--------------070008090102010507080905
Content-Type: text/plain; charset=us-ascii


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
--------------070008090102010507080905--