Bug 761186 - Java client mishandles tcp_nodelay when specified as part of the broker URL
Summary: Java client mishandles tcp_nodelay when specified as part of the broker URL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java
Version: 2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: 2.1.2
: ---
Assignee: Rajith Attapattu
QA Contact: ppecka
URL:
Whiteboard:
Depends On:
Blocks: 753238 783492
TreeView+ depends on / blocked
 
Reported: 2011-12-07 20:33 UTC by Justin Ross
Modified: 2012-04-30 17:53 UTC (History)
3 users (show)

Fixed In Version: qpid-java-0.14-1.el5
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2012-04-30 17:53:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0529 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging 2.1 security and enhancement update 2012-04-30 21:48:25 UTC

Description Justin Ross 2011-12-07 20:33:50 UTC 
See https://issues.apache.org/jira/browse/QPID-3659
Comment 1 Justin Ross 2011-12-07 20:53:48 UTC 
Fixed upstream at http://svn.apache.org/viewvc?view=rev&rev=1211611

Rajith, please provide verification steps.
Comment 2 Justin Ross 2011-12-08 15:06:29 UTC 
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.
Comment 4 Rajith Attapattu 2012-01-18 21:46:37 UTC 
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.
Comment 5 ppecka 2012-02-17 08:50:32 UTC 
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
Comment 7 Rajith Attapattu 2012-03-12 14:58:10 UTC 
    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.
Comment 8 errata-xmlrpc 2012-04-30 17:53:25 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/RHSA-2012-0529.html
Note You need to log in before you can comment on or make changes to this bug.