Why have you reversed my changes on replication?

[timfox]

+
+ private MessageReference removeReferenceOnBackup(final long id) throws Exception
+ {
+ // most of the times, the remove will work ok, so we first try it without any locks
+ MessageReference ref = messageQueue.removeFirstReference(id);

+ if (ref == null)
+ {
+ PagingStore store = pagingManager.getPageStore(binding.getAddress());
+
+ while (true)
+ {
+ // Can't have the same store being depaged in more than one thread
+ synchronized (store)
+ {
+ // as soon as it gets the lock, it needs to verify if another thread couldn't find the reference
+ ref = messageQueue.removeFirstReference(id);
+ if (ref == null)
+ {
+ // force a depage
+ if (!store.readPage()) // This returns false if there are no pages
+ {
+ break;
+ }
+ }
+ else
+ {
+ break;
+ }
+ }
+ }
+ }
+
+ return ref;
+
+ }
+
+

I removed that code for a reason. I changed replication to *guarantee* that order of all operations on backup is exactly the same as the order on the live node, so this is unnecessary.

[clebert.suconic]

PageFailoverStressTest was failing. There was a multi-thread-test on failover.

And I also added a test on the integration testsuite to also fail when the order is not respected.

Maybe the order is not being guaranteed.

[clebert.suconic]

I see that you reverted it.


PagingFailoverTest will fail.

[timfox]

Order is definitely guaranteed. You'd need to find the real reason the test is failing.

Maybe the order is ok, but it hasn't been depaged yet.

If so we'll need to continue to force a depage, but it'll be guaranteed to be in the first page read.

[timfox]

Ok i partially re-instated the force depage with some changes. PagingFailovreTest now passes

[clebert.suconic]

"timfox" wrote:
Order is definitely guaranteed.

Even among different producers?

[clebert.suconic]

"timfox" wrote:
Order is definitely guaranteed.

Even among different producers?

Please ignore this question :-)