When MessageConsumer#receive() is reading large message when failover happens, receive method returns null instead of throwing JMSException. I think this is a bug, because the client code then has no chance to distinguish between client close and failover.

The client gets following error on the output:

SEVERE: Failed to prepare message for delivery
java.lang.RuntimeException: Transmission interrupted on consumer shutdown
at org.hornetq.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:205)
at org.hornetq.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:101)
at org.hornetq.jms.client.HornetQMessage.doBeforeReceive(HornetQMessage.java:896)
at org.hornetq.jms.client.HornetQTextMessage.doBeforeReceive(HornetQTextMessage.java:141)
at org.hornetq.jms.client.HornetQMessageConsumer.getMessage(HornetQMessageConsumer.java:238)
at org.hornetq.jms.client.HornetQMessageConsumer.receive(HornetQMessageConsumer.java:134)
at com.redhat.msvehla.clients.Consumer.receiveMessage(Consumer.java:105)
at com.redhat.msvehla.clients.Consumer.run(Consumer.java:60)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: HornetQException[errorCode=110 message=Transmission interrupted on consumer shutdown]
at org.hornetq.core.client.impl.LargeMessageControllerImpl.cancel(LargeMessageControllerImpl.java:242)
at org.hornetq.core.client.impl.ClientConsumerImpl.resetLargeMessageController(ClientConsumerImpl.java:813)
at org.hornetq.core.client.impl.ClientConsumerImpl.clearAtFailover(ClientConsumerImpl.java:533)
at org.hornetq.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:1122)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:973)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:676)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:559)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.access$000(ClientSessionFactoryImpl.java:80)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1578)
at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:574)
at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:336)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl$Channel0Handler$1.run(ClientSessionFactoryImpl.java:1487)
at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
... 3 more

Notice that this RuntimeException is not thrown to client. It's printed to log.error and null is returned instead (see HornetQMessageConsumer#getMessage, line 242).

I was testing this on dedicated topology with shared journal, but I think it's general issue not specific to topology.

This was tested with EAP 5.3.0.ER2 (HornetQ 2.2.27.Final), but it is not regression, I found it when doing some new tests for EAP 5 - 6 interoperability test. So this is not blocker.