Bug 824985 - Federated links become stale after source broker host fails
Summary: Federated links become stale after source broker host fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 2.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: 3.0
: ---
Assignee: Ted Ross
QA Contact: Zdenek Kraus
URL:
Whiteboard:
Depends On:
Blocks: 698367
TreeView+ depends on / blocked
 
Reported: 2012-05-24 18:17 UTC by Jason Dillaman
Modified: 2014-09-24 15:04 UTC (History)
5 users (show)

Fixed In Version: qpid-0.18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-24 15:04:16 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA QPID-4040 0 None None None 2012-06-05 15:34:14 UTC
Red Hat Product Errata RHEA-2014:1296 0 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 3.0 Release 2014-09-24 19:00:06 UTC

Description Jason Dillaman 2012-05-24 18:17:01 UTC
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 18:21:32 UTC
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 18:36:22 UTC
Fixed upstream at revision 1347044.

Comment 3 Zdenek Kraus 2013-07-09 09:52:43 UTC
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 15:04:16 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/RHEA-2014-1296.html


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