Red Hat Bugzilla – Bug 755651
getJMSReplyTo does not return null for null ReplyTo property
Last modified: 2014-09-24 11:03:32 EDT
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
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()".
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.
Updated release flag to 2.1.x and target milestone to 2.1.2.
(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)
Btw. reproducer is attached in upstream JIRA: https://issues.apache.org/jira/secure/attachment/12504523/JMSReplyToTest.tar.gz
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.
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
This is tracked upstream via QPID-4617 Pavel's patch is committed at rev http://svn.apache.org/r1451727
I have also fixed the root cause at rev http://svn.apache.org/r1453041
Created attachment 781183 [details] Tar file containing test program source and test execution script.
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
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