Red Hat Bugzilla – Bug 761186
Java client mishandles tcp_nodelay when specified as part of the broker URL
Last modified: 2012-04-30 13:53:25 EDT
See https://issues.apache.org/jira/browse/QPID-3659
Fixed upstream at http://svn.apache.org/viewvc?view=rev&rev=1211611 Rajith, please provide verification steps.
The upstream fix has two consequences: 1. it logs the state of the tcp_nodelay setting, and 2. it alters the handling of boolean properties in connection urls.
As for verification. The client now defaults to tcp_nodelay=true if the user incorrectly specifies the value in the connection URL. We also log the value of tcp_nodelay. Verification is via visual inspection in debug mode.
Verified on RHEL5, RHEL6: except message is logged on "info" level 2012-02-12 20:12:30 info Set TCP_NODELAY on connection to [::1]:56647 # rpm -qa | grep qpid qpid-tests-0.14-1.el6.noarch rh-qpid-cpp-tests-0.14-6.el6.x86_64 qpid-java-common-0.14-1.el6.noarch qpid-tools-0.14-1.el6.noarch qpid-cpp-server-0.14-6.el6.x86_64 qpid-cpp-server-ssl-0.14-6.el6.x86_64 qpid-cpp-client-devel-docs-0.14-6.el6.noarch qpid-jca-0.14-7.el6.noarch qpid-cpp-client-0.14-6.el6.x86_64 qpid-cpp-client-ssl-0.14-6.el6.x86_64 qpid-qmf-0.14-3.el6.x86_64 qpid-cpp-server-rdma-0.14-6.el6.x86_64 qpid-cpp-server-store-0.14-6.el6.x86_64 ruby-qpid-0.7.946106-2.el6.x86_64 qpid-java-client-0.14-1.el6.noarch python-qpid-qmf-0.14-3.el6.x86_64 qpid-cpp-server-cluster-0.14-6.el6.x86_64 qpid-cpp-server-devel-0.14-6.el6.x86_64 ruby-qpid-qmf-0.14-3.el6.x86_64 qpid-cpp-client-devel-0.14-6.el6.x86_64 qpid-qmf-devel-0.14-3.el6.x86_64 qpid-cpp-debuginfo-0.14-6.el6.x86_64 qpid-java-example-0.14-1.el6.noarch qpid-cpp-client-rdma-0.14-6.el6.x86_64 python-qpid-0.14-3.el6.noarch fence-virtd-libvirt-qpid-0.2.3-5.el6.x86_64 qpid-cpp-server-xml-0.14-6.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: JMS client incorrectly defaults to false when tcp_nodelay property is incorrectly specified in the connection URL. Consequence: The JMS client TCP-NODELAY setting defaults to false (Should be true). Fix: The code now use true as the default value when trying to parse the connection URL. Result: The client defaults to true even if there is any error in the connection URL.
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/RHSA-2012-0529.html