Consuming messages with the python client, using an accept mode of explicit (the default) as demonstrated in the python tutorial causes the broker to consume extreme amounts of CPU. I've filed this under the broker component, however it's entirely possible that the client is triggering this by misbehaving, e.g. forgetting to ack messages.
I believe the problem is that the broker retains a record of each delivery and keeps this until the delivery has been accepted/released (at which point the message is released) AND completed. The reason that it holds them until completion is to have a record of the bytes to be reallocated in window mode when completion occurs. However this is only necessary for subscriptions that are in windowing mode. As the python client doesn't send completions automatically, the list of records builds up as messages are sent and this slows down processing of subsequent accepts.
Fixed by r704838 which prevents the broker from holding onto the records until completion is received unless it is in windowing mode. Also changed the mode used in start() on the incoming queue in the python client to be credit mode (which appears to be in keeping with the spirit of that method). To verify the test I modifed the pubsub python examples to allow a steady stream of messages to flow to the consumer. Prior to the change, after a large number of messages the broker CPU would start rise and remain high; with the change the test could run for a long period without any noticebale increase in broker load.
Created attachment 320409 [details] Test subscriber
Created attachment 320410 [details] Test publisher The attached publisher and subscriber were the tests I used to detect the issue andverify the fix. I ran the publisher in a loop (while ./examples/pubsub/mypub.py ; do true; done) while the subscriber was running and monitored the CPU usage.
RHTS test qpid_test_explicit_accept_mode_bz466955 proves that issue has been fixed. Validated on RHEL 4.7 / 5.2 i386 / x86_64 using packages: qpidd-0.3.713378-1.el5/rhm-0.3.2783-1.el5 vs. mrg 1.0.1 packages ->VERIFIED
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0035.html