Bug 824985 - Federated links become stale after source broker host fails
Federated links become stale after source broker host fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
2.0
Unspecified Unspecified
high Severity unspecified
: 3.0
: ---
Assigned To: Ted Ross
Zdenek Kraus
: Patch
Depends On:
Blocks: 698367
  Show dependency treegraph
 
Reported: 2012-05-24 14:17 EDT by Jason Dillaman
Modified: 2014-09-24 11:04 EDT (History)
5 users (show)

See Also:
Fixed In Version: qpid-0.18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-24 11:04:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-4040 None None None 2012-06-05 11:34:14 EDT

  None (edit)
Description Jason Dillaman 2012-05-24 14:17:01 EDT
Description of problem:
Create a federated link between source broker A to destination broker B (broker B is the client to broker A).  Broker A will send heartbeats to broker B and broker B will send back heartbeats after it receives one from broker A.  

If the broker A's host is hard-killed so that the TCP connection is not properly closed, broker B will continue to think it has an established connection to broker A.  Since broker B does not send heartbeats and does not have a heartbeat timeout timer running, broker B never notices that the TCP link is stale.  

Version-Release number of selected component (if applicable):
qpid-cpp-server-0.12-6_ptc_hotfix_3.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a standard pull queue route from broker A (source) to broker B (destination)
2. Hard kill the host for broker A
  
Actual results:
Broker B's connection to broker A remains ESTABLISHED and does not recover.

Expected results:
Broker B's connection will be re-established.

Additional info:
Comment 1 Jason Dillaman 2012-05-24 14:21:32 EDT
CLARIFICATION:

Expected results:
Broker B's TCP connection to broker A will disconnect and it will attempt to reconnect to broker A or one of its failover nodes (in a clustered environment).
Comment 2 Ted Ross 2012-06-06 14:36:22 EDT
Fixed upstream at revision 1347044.
Comment 3 Zdenek Kraus 2013-07-09 05:52:43 EDT
The fix works as expected.

Fix was tested on RHEL 5.9 and 6.4 on i686 and x86_64 architecture, with
packages:
python-qpid-0.22-4
python-qpid-qmf-0.22-5
qpid-cpp-client-0.22-6
qpid-cpp-client-devel-0.22-6
qpid-cpp-client-devel-docs-0.22-6
qpid-cpp-client-rdma-0.22-6
qpid-cpp-client-ssl-0.22-6
qpid-cpp-server-0.22-6
qpid-cpp-server-devel-0.22-6
qpid-cpp-server-ha-0.22-6
qpid-cpp-server-rdma-0.22-6
qpid-cpp-server-ssl-0.22-6
qpid-cpp-server-store-0.22-6
qpid-cpp-server-xml-0.22-6
qpid-proton-c-0.4-2.2
qpid-qmf-0.22-5
qpid-tools-0.22-2


->VERIFIED
Comment 5 errata-xmlrpc 2014-09-24 11:04:16 EDT
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

Note You need to log in before you can comment on or make changes to this bug.