The failover is blocking because client applications would fail and would require to block.. it's customer's code.
I reckon we could do asynchronously for MDBs or message listeners. so, how do you differentiate the two here?
I suspect Failover (FailoverTest and others on the testsuite) wouldn't work.
Also.. at least you should make this change on master.. it's a significant refactoring to make something like this to work properly. Failover itself was a pain.. making this level.. even more difficult.
@clebertsuconic The problem here is that any thread that blocks indefinitely takes up resources in the Thread pool. If you have several threads trying reconnect, the ThreadPool may be exhausted and can not be used to perform any other tasks. My opinion here is that no task we add to the ThreadPool should block indefinitely, for retry here we should attempt to connect, if it fails schedule another attempt connect call, and give up the thread. Jiri's made a start on that, but we may need to flesh out some of the details. There's a similar problem with LargeMessage receive().