As part of 1006, ChannelSupport:recoverDeliveries will throw an exception if it can't find a delivery to recover on messageRefs.

This will certainly cause Failover to fail... so the connection that couldn't get a proper failover should be invalidated in such state that no invocation should be made.

But it happens that a messageConsumer.receive() is going through ok, even if the failover was aborted.

I have tried few combinations such as closing the connectionDelegate on FailoverCommandCenter, but it didn't work as a close would try to communicate on server.

So I want to create a method on DelegateSupport, called invalidate, which will be intercepted by ClosedInterceptor and will throw an exception to any call to any Delegate that failed after a failover. This way a call to messageConsumer.receive() would throw a proper exception to the client.

The only things that execute in a transactional context are sending and ack of messages. These are the only things for which we give a transactional guarantee.

Cancelling and recovering don't need to be atomic.

Why?

Imagine if the cancel or recovery of several message failed half way. The session would eventually get closed and the remaining messages would end up back on the queue. No messages would be lost and we wouldn't have broken any of our transactional promises.

Imagine if the cancel or recovery of several message failed half way. The session would eventually get closed and the remaining messages would end up back on the queue. No messages would be lost and we wouldn't have broken any of our transactional promises.

This is not the behavior I saw on testcases..

The exception was breaking failover... and messages were getting lost. (Until a restart on server)

The problem was failover was interrupting failover and keepting the session half way. I have fixed the order where the client is set already (before failover). I will try closing the session when this happens.