Bug 466955 - problems with explicit accept mode
problems with explicit accept mode
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.0
All Linux
urgent Severity urgent
: 1.1
: ---
Assigned To: Gordon Sim
Kim van der Riet
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-14 14:30 EDT by Rafael H. Schloming
Modified: 2014-12-01 18:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 832512 (view as bug list)
Environment:
Last Closed: 2009-02-04 10:35:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test subscriber (3.12 KB, text/x-python)
2008-10-15 06:10 EDT, Gordon Sim
no flags Details
Test publisher (2.15 KB, text/x-python)
2008-10-15 06:12 EDT, Gordon Sim
no flags Details

  None (edit)
Description Rafael H. Schloming 2008-10-14 14:30:59 EDT
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.
Comment 1 Gordon Sim 2008-10-15 06:00:22 EDT
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.
Comment 2 Gordon Sim 2008-10-15 06:09:13 EDT
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.
Comment 3 Gordon Sim 2008-10-15 06:10:29 EDT
Created attachment 320409 [details]
Test subscriber
Comment 4 Gordon Sim 2008-10-15 06:12:40 EDT
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.
Comment 6 Frantisek Reznicek 2008-11-14 05:24:02 EST
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
Comment 8 errata-xmlrpc 2009-02-04 10:35:25 EST
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

Note You need to log in before you can comment on or make changes to this bug.