Following the IRC discussion, these are the issues I mentioned there. Regarding HORNETQ-832.
We have many tests in ReplicatedPagedFailoverTest that will make the backup server fail-over with paging data in disk. This triggers what it seems to be a page cursor bug.
New messages sent after fail-over will get AFAICT an incorrect page-position, and later these messages will be invalidaded
by the check on PageCursorInfo.isRemoved() from CursorIterator.moveNext(). See the JIRA case for details. If we open a new page at the end of PagingStoreImpl.start()
everything works. The (posited) cursor bug is likely hidden by the position reset.
One unrelated paging failure is from ReplicatedPagedFailoverTest.testTransactedMessagesSentSoRollbackAndContinueWork(), a classic synchronization issue. If I delay the check on the existing message, it always passes. The fact that the session committed, and that we use consumer.receiveImmediate() makes IMO it a real bug.
I wasn't sure if you were relating to Replication...
I will have to take a look on replication/paging after I'm done with merging...
There are a few considerations to be taken with the LivePage on replication... I need to look at how you're dealing with those between replication state and activation.