Bug 755651

Summary: getJMSReplyTo does not return null for null ReplyTo property
Product: Red Hat Enterprise MRG Reporter: Pavel Moravec <pmoravec>
Component: qpid-javaAssignee: Rajith Attapattu <rattapat+nobody>
Status: CLOSED ERRATA QA Contact: Irina Boverman <iboverma>
Severity: low Docs Contact:
Priority: medium    
Version: 2.1CC: ctrianta, iboverma, jross, lzhaldyb, mmahudha
Target Milestone: 3.0Keywords: EasyFix, Patch
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: qpid-java-0.22 Doc Type: Bug Fix
Doc Text:
It was discovered that the replyTo structure in getJMSReplyTo was checked for null values, however it's attributes were not checked. The replyTo struct could be set with null for the exchange and routing key, which resulted in a Destination being created with the exchange and routing key set to null on the receivers side. The fix checks for a null exchange and routing key, and returns null. This allows getJMSReplyTo to return null as designed.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-24 15:03:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Simple patch proposal
none
Tar file containing test program source and test execution script. none

Description Pavel Moravec 2011-11-21 17:32:54 UTC 
Description of problem:
Java client library wrongly returns reply-to via Message::getJMSReplyTo method for a message with setJMSReplyTo(null) called before.


Version-Release number of selected component (if applicable):
any (incl. 2.1)

How reproducible:
100%

Steps to Reproduce:
Use attached JUnit test. In short, the test performs:
1. msg.setJMSReplyTo(null);
2. producer.send(msg);
3. msg = consumer.receive();
4. msg.getJMSReplyTo() now returns:
:////?routingkey=''


Actual results:
msg.getJMSReplyTo() now returns:
:////?routingkey=''


Expected results:
msg.getJMSReplyTo() should return null


Additional info:
possible patch to be proposed
Comment 1 Pavel Moravec 2011-11-21 17:44:00 UTC 
JIRA case created: https://issues.apache.org/jira/browse/QPID-3636

The root cause of the bug is in calling:

AMQMessageDelegate_0_10.java:

    public Destination getJMSReplyTo()
    {
        ReplyTo replyTo = _messageProps.getReplyTo();

        if (replyTo == null)
        {
            return null;
        }
        else
        {

The _messageProps.getReplyTo() does not return null but "ReplyTo()".
Comment 4 Rajith Attapattu 2012-01-18 21:51:43 UTC 
This is a fairly low priority issue.
From an operational stand point IMO this has very little impact.

Given the high priority items we have on the plate, I would aim to fix this for 0.16 Qpid release if there is time.

Beyond that release, this will not be relevant as we might switch to the new client.
Comment 5 Irina Boverman 2012-01-20 17:32:29 UTC 
Updated release flag to 2.1.x and target milestone to 2.1.2.
Comment 7 Pavel Moravec 2012-08-09 11:59:19 UTC 
(In reply to comment #4)
> This is a fairly low priority issue.
> From an operational stand point IMO this has very little impact.
> 
> Given the high priority items we have on the plate, I would aim to fix this
> for 0.16 Qpid release if there is time.
> 
> Beyond that release, this will not be relevant as we might switch to the new
> client.

Is the new client available in qpid-java-0.18? As checking qpid-java-*-0.18-1.el5 packages, the error is still there.

Or does 0.18 client offer a different API for that?

(I am happy to fix this if it makes sense, just let me know)
Comment 8 Pavel Moravec 2012-08-09 12:00:40 UTC 
Btw. reproducer is attached in upstream JIRA: https://issues.apache.org/jira/secure/attachment/12504523/JMSReplyToTest.tar.gz
Comment 9 Pavel Moravec 2012-08-13 13:10:59 UTC 
Created attachment 604001 [details]
Simple patch proposal

Simple patch proposal.

If message properties has "empty" ReplyTo, then default ReplyTo constructor is called having exchange and routingKey undefined (i.e. null). Thus extending the if statement.
Comment 11 Rajith Attapattu 2013-03-01 21:32:49 UTC 
Christos,

I'm will put in a fix for this specific case.

However I'm wondering why they are explicitly trying to set the replyTo field as null. If you don't specify it, then you get null as expected when you to getJMSReplyTo.

Regards,

Rajith
Comment 12 Rajith Attapattu 2013-03-01 22:24:30 UTC 
This is tracked upstream via QPID-4617
Pavel's patch is committed at rev http://svn.apache.org/r1451727
Comment 13 Rajith Attapattu 2013-03-07 19:52:27 UTC 
I have also fixed the root cause at rev http://svn.apache.org/r1453041
Comment 14 Irina Boverman 2013-07-31 14:32:03 UTC 
Created attachment 781183 [details]
Tar file containing test program source and test execution script.
Comment 15 Irina Boverman 2013-07-31 14:35:23 UTC 
VERIFIED on RHEL 6, X86_64 and i686:

Test script output:

JUnit version 4.5
.
Time: 0.769

OK (1 test)

Installed packages:

# rpm -qa | egrep "qpid|qmf" | sort
perl-qpid-0.22-5.el6.x86_64
perl-qpid-debuginfo-0.22-5.el6.x86_64
python-qpid-0.22-4.el6.noarch
python-qpid-proton-0.4-2.2.el6.x86_64
python-qpid-proton-doc-0.4-2.2.el6.x86_64
python-qpid-qmf-0.22-7.el6.x86_64
qpid-cpp-client-0.22-8.el6.x86_64
qpid-cpp-client-devel-0.22-8.el6.x86_64
qpid-cpp-client-devel-docs-0.22-8.el6.noarch
qpid-cpp-client-rdma-0.22-8.el6.x86_64
qpid-cpp-client-ssl-0.22-8.el6.x86_64
qpid-cpp-debuginfo-0.22-8.el6.x86_64
qpid-cpp-server-0.22-8.el6.x86_64
qpid-cpp-server-devel-0.22-8.el6.x86_64
qpid-cpp-server-ha-0.22-8.el6.x86_64
qpid-cpp-server-rdma-0.22-8.el6.x86_64
qpid-cpp-server-ssl-0.22-8.el6.x86_64
qpid-cpp-server-store-0.22-8.el6.x86_64
qpid-cpp-server-xml-0.22-8.el6.x86_64
qpid-java-client-0.22-5.el6.noarch
qpid-java-common-0.22-5.el6.noarch
qpid-java-example-0.22-5.el6.noarch
qpid-proton-c-0.4-2.2.el6.x86_64
qpid-proton-c-devel-0.4-2.2.el6.x86_64
qpid-proton-debuginfo-0.4-2.2.el6.x86_64
qpid-qmf-0.22-7.el6.x86_64
qpid-qmf-debuginfo-0.22-7.el6.x86_64
qpid-qmf-devel-0.22-7.el6.x86_64
qpid-snmpd-debuginfo-1.0.0-12.el6.x86_64
qpid-tests-0.22-4.el6.noarch
qpid-tools-0.22-3.el6.noarch
rh-qpid-cpp-tests-0.22-8.el6.x86_64
ruby-qpid-qmf-0.22-7.el6.x86_64

----------

# rpm -qa | egrep "qpid|qmf" | sort
python-qpid-0.22-4.el6.noarch
python-qpid-qmf-0.22-7.el6.i686
qpid-cpp-client-0.22-8.el6.i686
qpid-cpp-client-devel-0.22-8.el6.i686
qpid-cpp-client-devel-docs-0.22-8.el6.noarch
qpid-cpp-client-rdma-0.22-8.el6.i686
qpid-cpp-client-ssl-0.22-8.el6.i686
qpid-cpp-debuginfo-0.22-8.el6.i686
qpid-cpp-server-0.22-8.el6.i686
qpid-cpp-server-devel-0.22-8.el6.i686
qpid-cpp-server-ha-0.22-8.el6.i686
qpid-cpp-server-rdma-0.22-8.el6.i686
qpid-cpp-server-ssl-0.22-8.el6.i686
qpid-cpp-server-store-0.22-8.el6.i686
qpid-cpp-server-xml-0.22-8.el6.i686
qpid-cpp-tar-0.22-8.el6.noarch
qpid-java-client-0.22-5.el6.noarch
qpid-java-common-0.22-5.el6.noarch
qpid-java-example-0.22-5.el6.noarch
qpid-proton-c-0.4-2.2.el6.i686
qpid-proton-c-devel-0.4-2.2.el6.i686
qpid-proton-debuginfo-0.4-2.2.el6.i686
qpid-qmf-0.22-7.el6.i686
qpid-qmf-debuginfo-0.22-7.el6.i686
qpid-qmf-devel-0.22-7.el6.i686
qpid-snmpd-1.0.0-12.el6.i686
qpid-snmpd-debuginfo-1.0.0-12.el6.i686
qpid-tests-0.22-4.el6.noarch
qpid-tools-0.22-3.el6.noarch
rh-qpid-cpp-tests-0.22-8.el6.i686
Comment 21 errata-xmlrpc 2014-09-24 15:03:32 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