Bug 678463 - Reconnect doesn't work intuitively - i.e. doesn't "automatically" reconnect
Summary: Reconnect doesn't work intuitively - i.e. doesn't "automatically" reconnect
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.3
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: ---
Assignee: Gordon Sim
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-18 02:40 UTC by William Henry
Modified: 2014-04-30 20:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-30 20:06:26 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA QPID-2798 0 None None None Never

Description William Henry 2011-02-18 02:40:03 UTC
Description of problem:

With a Connection to 127.0.0.1:5672 and reconnect-url:
 "{reconnect-urls:'amqp:tcp:127.0.0.1:5674', reconnect:true, heartbeat: 1}"

It would suggest that if two brokers (non-clustered) are running and the client is connected to the primary (5672), if the primary goes down the client would automatically failover.

However:

1. No failover will occur unless a Session has been established. So if the Connection is opened and then dropped the client does NOT failover. However if a Session is created on the Connection then the client can failover (not will failover - see 2).

2. Even with the heartbeat the client does NOT failover until some other action is peformed on the Session. So, for example, a myConnection.isOpen() will not (re)establish the connection to the failover broker.

It's been suggested that with reconnect:true a call to isOpen() should always return true* - i.e. if the connection is down then attempt to failover.

*unless the secondary (or others) is down too.
 
With heartbeat one might expect that the heartbeat casues an isOpen to be called. (?)

Version-Release number of selected component (if applicable):


How reproducible:
(easy to do in Ruby in irb - still uses the C++ client.

Bring up two brokers with trace.  
Create a connection to a primary with a reconnect-url like the above. Open the connection.  
Watch the heartbeats on the primary.
Kill the primary.
Run isOpen on the connection. It returns false. It does NOT failover.

Repeat the above but before killing the primary broker, create a session and create a receiver.
Kill the primary.
Create another (or same) receiver on the session. It will failover.



Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:


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