Bug 1009422 - consumed text message content is always <void> when using drain example
consumed text message content is always <void> when using drain example
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Unspecified Unspecified
medium Severity high
: 3.0
: ---
Assigned To: Gordon Sim
Petr Matousek
Depends On:
  Show dependency treegraph
Reported: 2013-09-18 08:14 EDT by Petr Matousek
Modified: 2015-01-21 07:57 EST (History)
4 users (show)

See Also:
Fixed In Version: qpid-cpp-0.22-16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-5141 None None None Never

  None (edit)
Description Petr Matousek 2013-09-18 08:14:19 EDT
Description of problem:

Following change was done between qpid-cpp-client-devel-0.22-13 and
qpid-cpp-client-devel-0.22-14 in drain client:
<                     std::cout << message.getContent();
>                     std::cout << message.getContentObject();

As the content object is not filled by spout on sending a text message, the getContentObject() call always returns <void>.

Note: sending ie.: mapMessage do not suffer from that (spout correctly fills the content object)

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

How reproducible:

Steps to Reproduce:
1. drain -f amq.direct
2. spout --content "textMessage" amq.direct
3. the consumed message content is <void>

Actual results:
Consumed message content is always <void>

Expected results:
Consumed message content is properly displayed

Additional info:
./drain -f amq.direct
Message(properties={spout-id:efee0070-658e-4e7d-a3ff-5d4f0c700130:0, x-amqp-0-10.routing-key:}, content='<void>')
Comment 2 Gordon Sim 2013-09-18 15:24:58 EDT
Fixed upstream: https://svn.apache.org/r1524505
Comment 4 Petr Matousek 2013-10-25 05:23:27 EDT
This issue has been fixed. Verified on rhel6.4 (i386, x86_64).

packages used for testing:

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