Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-49

Replication replay does not take into consideration the server/backend's writability mode.

    Details

    • Support Ticket IDs:
    • Sprint:
      Sprint 10, Sustaining Sprint 1, Sustaining Sprint 2, Sustaining Sprint 3, Sustaining Sprint 4, DJ Sustaining 4, DJ Sustaining 5, DJ Sustaining 6, DJ Sustaining 7, DJ Sustaining 8, DJ Sustaining 9, DJ Sustaining Sprint 10, DJ Sustaining Sprint 12

      Description

      Replication replay threads should block replaying operations when they detect that the server and/or backend is read-only. Currently the operation fails with UNWILLING_TO_PERFORM (if server is read-only) or NO_SUCH_OBJECT (if backend is unavailable due to e.g. rebuild).

      There are a couple of difficulties here:

      1) What should the replay thread do when it detects that the operation cannot be replayed? Should it back off for a short period and retry? How long should it continue trying, knowing that tasks such as rebuild index may take quite a long time?

      2) How should a replay thread detect that a backend is only temporarily offline due to import/rebuild? There is no way currently to distinguish between a backend which is temporarily offline and one which has been removed altogether, since both require that the backend be disabled in the configuration. We had hoped to address this class of problem (separation of config and state) in 3.0.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                patrickdiligent patrick diligent
                Reporter:
                matthew Matthew Swift
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: