Ticket 51190 - SyncRepl plugin provides a wrong cookie
Bug description:
A sync repl thread is similar to persistent search thread.
The server is communicating with the sync repl thread with
an ordered queue of updates.
Updates are written in the queue by post op callbacks.
Sync repl thread waits/reads the queue, retrieve the updates
from the retroCL, checks if target entry matches the
request (scope/filter) and send back the entry/update to
the sync repl client.
Several issues regarding the way order of the updates in
the queue:
(1) When an update generates nested updates (automemeber,
memberof,...) the order of the updates in the queue is
not following the order of applied updates. The consequence
is that the cookie (containing the update nubmer) can be wrong.
It can contains jumps, disorder and invalid number (-1).
When an update fails (nested or primary update), none of the
updates should be pushed to sync_repl queue
(2) The plugin callback on updates are POSTOP, so if there are
two direct updates, there is a possibility that the callback
of the second update (and its nested updates) are enqueued
before the first update. In such case the sync_repl thread
may skip some updates and/or fail to retrieve update from
retroCL (cookie.update_no=-1)
Fix description:
The fix does
(1) implements a pending list of updates (in the thread
private space "get_thread_primary_op").
The first in the pending list is the primary update then
the others are the nested updates.
A new operation (betxn_preop) registers the operation at
the end of the pending list with the state OPERATION_PL_PENDING.
It requires to registers new callbacks (sync_betxn_preop_init)
During be_postop (see below) callbacks flags the pending
updates as OPERATION_PL_SUCCEEDED or OPERATION_PL_FAILED
depending on the operatione result.
When no more pending updates are OPERATION_PL_PENDING,
then depending of the result of the primary update
(OPERATION_PL_SUCCEEDED or OPERATION_PL_FAILED) the
updates are moved to the sync_repl queue.
(2) The postop plugin callbacks are now be_postop
https://pagure.io/389-ds-base/issue/51190
Reviewed by: Mark Reynolds, Simon Pichugin, William Brown (Thanks)
Platforms tested: F31