Core bridges lose messages when paging

[jmesnil]

re https://jira.jboss.org/browse/HORNETQ-382.

I've committed a test which shows the issue in BridgeWithPagingTest.testReconnectWithPaging.

The issue is that when the bridge reconnects to the 2nd server, messages which should be paged are not paged and they're lost.

After some debugging, it seems there is an issue in PostOfficeImpl.route() when we page the messages (circa line 616):

         boolean depage = context.getTransaction().getProperty(TransactionPropertyIndexes.IS_DEPAGE) != null;

         if (!depage && message.storeIsPaging())
         {
            getPageOperation(context.getTransaction()).addMessageToPage(message);

            return;
         }

We return after adding the message to the page in the page operation but we did not commit the transaction (which was started line 597).

AIUI, the message will in fact never be really added to the page as the getPageOperation() will not be completed if the tx is not committed.

I'll continue to investigate a bit...

[robertjlee]

Hi Jeff,

Is this still an issue? The JIRA still shows as unresolved, but it hasn't been worked on in a while and losing messages seems like it might be a serious issue?  Further to the dialogue between Tim Fox and Luca Padovan we are losing messages while depaging a core queue entirely on the server with no Client side, hence, no ack-batch-size complications. (It seemed to happen again with HornetQ-2.1.2-final stand-alone).

The term ack-batch-size is only referred to in the manual in the yellow box that Tim Fox refers to, so we assume that it can't be set on eg a server side bridge.

We are currently working on a work-around related to:

https://community.jboss.org/message/560914