Steps to reproduce:
1. Start up a reverse proxy server listening on a known port, for example 9999. I used Charles for this. Can start Charles, select Charles -> Preferences -> Reverse Proxies and enter "9999,localhost:8400" in the Proxy Mappings.
2. Edit the services-config.xml file for the qa-manual webapp and set the port for the data-polling-amf channel to 9999.
<channel-definition class="mx.messaging.channels.AMFChannel" id="data-polling-amf">
<endpoint class="flex.messaging.endpoints.AMFEndpoint" url="http://{server.name}:9999/{context.root}/messagebroker/amfpolling"></endpoint>
<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-millis>5000</polling-interval-millis>
</properties>
</channel-definition>
3. Start tomcat on blazeds/trunk.
4. Run the MessagingApp in the qa-manual webapp:
http://localhost:8400/qa-manual/messaging/MessagingApp.mxml.
5. In the consumer section of the app select data-polling-amf for the channel and click the "Add Channel" button. Repeat this process for a different channel so that there are two channels in the channel set.
6. Click the subscribe button and verify that the consumer is subscribed and connected through the reverse proxy on port 9999.
7. Kill the reverse proxy (Charles).
Actual Results: The consumer keeps trying to resubscribe over the data-polling-amf channel until the resubscribe attempts limit is reached at which point it gives up.
Expected Results: Would expect the consumer to try to reconnect over the data-polling-amf channel once and then failover to the next available channel in the channel set.
Workaround (if any):
Bug
Closed
Channel failover not working correctly on blazeds/trunk. 
1. Client connects
2. Connection fails and client notices, dispatching a ChannelFaultEvent or ChannelEvent.DISCONNECT
* breakpoint client
3. Restore connection (by say, restarting the proxy)
* run client from breakpoint
4. Immediately following the fault or disconnect event, the Channel will reconnect to the same current URL, which will succeed resulting in the dispatch a connect event.
The scenario here is to survive a _very_ transient disconnect due to a proxy or firewall closing an idle connection. But the proxy or firewall is still running and will accept the nearly immediate reconnect attempt from the client. If the proxy, firewall or server is killed this immediate reconnect attempt fails and is followed by our regular channel failover and channelset hunting logic.