Bug 904010
| Summary: | connectdelay parameter ignored for the first broker in brokerlist | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Pavel Moravec <pmoravec> | ||||||
| Component: | qpid-java | Assignee: | Rajith Attapattu <rattapat+nobody> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Irina Boverman <iboverma> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 2.2 | CC: | iboverma, jross, lzhaldyb | ||||||
| Target Milestone: | 3.0 | Keywords: | Patch, TestCaseProvided | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | qpid-java-0.22-1.el5, qpid-java-0.22-2.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
It was discovered that a redundant doDelay variable caused the connectdelay parameter to be ignored for the first broker. The
connectdelay parameter was ignored for the very first broker listed in brokerlist, and any retry attempt was done immediately for this broker. The fix removes the redundant doDelay parameter, which allows the Java client to use the connectdelay before attempting reconnection.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 987578 (view as bug list) | Environment: | |||||||
| Last Closed: | 2014-09-24 15:06:02 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 987578 | ||||||||
| Attachments: |
|
||||||||
Created attachment 687358 [details]
Simple patch proposal
Remove redundant doDelay variable that directly causes the connectdelay parameter ignored for first broker.
http://svn.apache.org/r1456131 Applied Pavel's patch. Created attachment 781352 [details]
Tar file containing test program source and test execution script.
Re connection is handled differently with the new client. The delay calculated using an exponential backoff algorithm subject to a ceiling specified by the max_delay parameter. 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 |
Description of problem: connectdelay parameter is ignored for the very first broker listed in brokerlist. Any retry attempt is done immediately for this broker. Version-Release number of selected component (if applicable): qpid-java-*0.18-2 How reproducible: 100% Steps to Reproduce: # cleanup and start 3 brokers in a cluster killall qpidd for port in 5001 5002 5003; do rm -rf _${port}; mkdir _${port}; done port=5001; qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & port=5002; qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & port=5003; qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & # now run a client with connection URL: # "amqp://guest:guest@test/?failover='roundrobin?cyclecount='1000''&brokerlist='tcp://localhost:5001?retries='10'&connectdelay='1000'&connecttimeout='1000000';tcp://localhost:5002?retries='10'&connectdelay='1'&connecttimeout='1';tcp://localhost:5003?retries='10'&connectdelay='1'&connecttimeout='1''" # that means, the client should try to re-connect to 5001 broker 100times per 1 second # bounce brokers such that the client re-connects to subsequent broker - doing this cycle is required until bz896570 is fixed, then we can ignore next 3 lines port=5001; kill $(ps aux | grep qpid | grep "port=${port} " | awk '{ print $2 }'); sleep 15; qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & port=5002; kill $(ps aux | grep qpid | grep "port=${port} " | awk '{ print $2 }'); qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & port=5003; kill $(ps aux | grep qpid | grep "port=${port} " | awk '{ print $2 }'); qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & port=5001; kill $(ps aux | grep qpid | grep "port=${port} " | awk '{ print $2 }'); qpidd --port=$port --store-dir=_${port} --data-dir=_${port} --auth=no --cluster-name=MyCluster --log-to-stderr=no > /dev/null 2>&1 & Actual results: Client is connected to broker 5002. Optional checking of INFO logs show that lines like: INFO [IoReceiver - train1/10.34.1.241:5003] (FailoverRoundRobinServers.java:166) - Delay between connect retries:1 appear _only_ whe trying to re-connect to broker 5002 and/or 5003, but does not appear when reconnecting to broker 5001 (as the parameter is ignored). Expected results: Assuming broker re-start is fast (within 10 seconds), the client should be connected to broker 5001. Optionally, this can be double-checked by the log above occuring also for reconnecting to broker 5001. Additional info: Patch to be proposed.