1 Reply Latest reply on Jan 24, 2012 11:25 AM by Clebert Suconic

    HORNETQ-832 Failing Paging tests

    borges Novice



      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.

        • 1. Re: HORNETQ-832 Failing Paging tests
          Clebert Suconic Master

          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.