Fix for cursor reset after topic reload

[merlimat]

Motivation

As reported in #309, the cursor reset operation will fail after a topic reload when no new mark-delete operation was issued, since the cursor ledger was set to a read-only ledger.

Modifications

Changed the reset logic to rely on internalAsyncMarkDelete() which forces to create a new ledger when the cursor is in NoLedger state.

Fix #309

[merlimat]

cc @sschepens

[rdhabalia]

so, if we don't initialize cursorLedger at the time recovery then it will be null initially and at that time internal-stat will not return correct value of cursorLedgerLastEntry. So, is there any specific reason to not initialize it at recovery time?

[merlimat]

very good point. I removed it because it is confusing to use the same variable to store 2 different kinds of ledger handler (one read-write and the other read-only)

Anyway I think it still make sense for the internal stats. In this case we would see:

cursorLedger = -1
cursorLedgerLastEntry = -1

and that is appropriate since we are in NoLedger state.

This below is the code that returns the -1:

  public long getCursorLedger() {
        LedgerHandle lh = cursorLedger;
        return lh != null ? lh.getId() : -1;
    }

    public long getCursorLedgerLastEntry() {
        LedgerHandle lh = cursorLedger;
        return lh != null ? lh.getLastAddConfirmed() : -1;
    }

[rdhabalia]

internalFlushPendingMarkDeletes just clears previous pendingMarkDeleteOps and not completes the callback of PendingMarkDeleteEntry and there could be possibility if someone is waiting for the callback. One example PersistentReplicator waiting to just do debug-log and which is fine but just concern is that as it has callback so, one can wait on it..

[merlimat]

Actually, that is covered 😉

Take a look at internalMarkDelete(), there's this code there:

// Trigger the final callback after having (eventually) triggered the switchin-ledger operation. This
                // will ensure that no race condition will happen between the next mark-delete and the switching
                // operation.
                if (mdEntry.callbackGroup != null) {
                    // Trigger the callback for every request in the group
                    for (PendingMarkDeleteEntry e : mdEntry.callbackGroup) {
                        e.callback.markDeleteComplete(e.ctx);
                    }
                } else {
                    // Only trigger the callback for the current request
                    mdEntry.callback.markDeleteComplete(mdEntry.ctx);
                }

So, 1 single write and triggers all the callbacks

[rdhabalia]

I see.

[rdhabalia]

👍