Bug 678463

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: