Bug 1128653

Summary: nextReceiver() with IMMEDIATE duration always returns null
Product: Red Hat Enterprise MRG Reporter: Gordon Sim <gsim>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED ERRATA QA Contact: Zdenek Kraus <zkraus>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.0CC: gsim, iboverma, jross, lzhaldyb, pematous, zkraus
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-cpp-0.22-47 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1128654 (view as bug list) Environment:
Last Closed: 2014-09-24 15:12:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1128654    

Description Gordon Sim 2014-08-11 09:59:02 UTC
Description of problem:

Calling Session::nextReceiver() with a duration of IMMEDIATE will always return null, even if there are incoming messages waiting. This bug was introduced as part of the fix for bug 958895.

Version-Release number of selected component (if applicable):

qpid-0.24, mrg 2.3.3, qpid-0.28

How reproducible:

Easily

Steps to Reproduce:
1. put some messages in a queue
2. have a program that creates a receiver for the queue, sets a non-zero capacity, then loops until nextReceiver(Duration::IMMEDIATE returns a non-null receiver), e.g.:

   ssn.createReceiver("my-queue").setCapacity(1);
   Receiver next;
   while (ssn.nextReceiver(Duration::IMMEDIATE)) {}
   next.get(Duration::IMMEDIATE)


Actual results:

The while loop never returns, even though there are messages on the queue

Expected results:

The while loop exits once the broker has sent out (a) message(s)

Additional info:

It should be pointed out that using nextReceiver() with a Duration::IMMEDIATE value in this way is inefficient and rather odd. A much better solution would be to specify some non-zero timeout. This would avoid the cpu usage of a 'busy wait' while in no way either increasing the actual time until the next receiver is obtained or the maximum theoretical time.

Using nextReceiver() with a non-zero timeout also avoids this bug.

Comment 1 Gordon Sim 2014-08-11 10:02:05 UTC
Code snippet above should read:

   ssn.createReceiver("my-queue").setCapacity(1);
   Receiver next;
   while (ssn.nextReceiver(next, Duration::IMMEDIATE)) {}
   next.get(Duration::IMMEDIATE);

(i.e. the receiver handle to be set should be passed in to the nextReceiver() call).

Comment 3 Gordon Sim 2014-08-11 11:31:24 UTC
Fixed upstream: https://svn.apache.org/r1617256

Comment 4 Gordon Sim 2014-08-14 12:50:19 UTC
The commit above fixes one regression but introduces another. Need https://svn.apache.org/r1617924 also from upstream.

Comment 9 Zdenek Kraus 2014-08-25 13:17:03 UTC
This fix was tested on RHEL 6.5 i686 && x86_64 with following packages:

qpid-cpp-server-0.22-47.el6
qpid-cpp-server-rdma-0.22-47.el6
qpid-cpp-server-xml-0.22-47.el6
qpid-cpp-client-0.22-47.el6
qpid-cpp-client-devel-0.22-47.el6
qpid-cpp-client-rdma-0.22-47.el6
qpid-cpp-server-ha-0.22-47.el6
qpid-cpp-server-linearstore-0.22-47.el6
qpid-cpp-debuginfo-0.22-47.el6
qpid-cpp-server-devel-0.22-47.el6
qpid-cpp-client-devel-docs-0.22-47.el6

works as expected.

Comment 10 errata-xmlrpc 2014-09-24 15:12:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2014-1296.html