[jira] Commented: (DERBY-3071) Replication: Modify logging subsystem for slave replication mode

["Øystein Grøvlen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536690 ] 

Øystein Grøvlen commented on DERBY-3071:
----------------------------------------

Thanks for the patch, Jørgen.  My review of this patch are more
questions than comments since I am not quite sure I have grasped all
the intricacies here:

1. I do not feel the relationship between logFileNumber and
   bootTimeLogFileNumber is quite clear from the comments.  

   a) I think it would be good if you could explicitly say what will
      be the state of these two after boot, during recovery, and after
      recovery has completed.

   b) recover(): Comment say that logFileNumber is determined at boot
      time.  Is this still true?

   c) I do not understand comment for assignment logFileNumber =
      bootTimeLogFileNumber.  Comment says bootTimeLogFileNumber is not
      needed anymore. Then, why the assignment?

   d) I do not quite understand why you need to set logFileNumber to
      bootTimeLogFileNumber at end of recovery since the next thing
      you will normally do is to set it to something else based on
      logEnd.

   e) Comment says that logFileNumber is only changed by
      switchLogFile. I guess that is not strictly true.

   f) Comments for these fields are (partly?) below the declaration.
      This is a bit unorthodox, and I feel some empty lines could be
      added in order to make clear whether comments for declaration of
      fields apply to field above or below comment.

   g) I think it would be good with I comment that states why you
      have to wait for the first log file to be complete in the
      beginning of recover().  I guess it because
      getLogFileAtBeginning is not called on this file.  Hence, the
      normal stop mechanism will not work.  Given that you have this
      test, is the test for slaveRecoveryBlocked really needed?

2. What is preventing someone from executing slave start before boot
   has completed?  I would think that could create some nasty race
   conditions.  (E.g., if initializeSlaveReplication() uses
   logFileNumber before it has been initialized by boot()).  Maybe it
   is the responsibility of the caller to synchronize this, but then
   the javadoc for initializeSlaveReplication() should say so.

3. What happens if failover is initiated before the first log file
   switch?  Will not that require a notification and that
   allowedToReadFileNumber is updated in order to get recovery going?

4. getLogFileAtBeginning():

   a) I think the assumption that this is only called by the recovery
      thread (at least while in slave replication mode), should be
      documented in the Javadoc.

   b) Is the MT comment in the javadoc still valid?


5. Add exceptions to javadoc for initializeSlaveReplication?



> Replication: Modify logging subsystem for slave replication mode
> ----------------------------------------------------------------
>
>                 Key: DERBY-3071
>                 URL: https://issues.apache.org/jira/browse/DERBY-3071
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services, Store
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: derby-3071_continuous-recovery_1a.diff, derby-3071_continuous-recovery_1a.stat, derby-3071_continuous-recovery_1b.diff
>
>
> When a database is booted in slave replication mode, it should apply log records received from the master but must not generate log by itself. As described in the functional specification (see DERBY-2872), a database booted in slave mode should enter LogToFile#recover, but not leave this method until the database is no longer in slave mode. 
> The current plan for this issue is to modify LogToFile the following ways:
> * LogToFile is put in slave mode automatically during boot (if property SlaveFactory.SLAVE_MODE is set, see DERBY-3021), but a method is needed to take LogToFile out of recovery mode.
> * SlaveFactory (DERBY-3021) will receive log records from the master and use LogToFile#appendLogRecord to write these to disk. While in slave mode, only SlaveFactory will be allowed to append log records.
> * The thread running LogToFile#recover will recover (redo) one log file at a time (like now), but will not be allowed to open a log file X until that file is no longer being written to. Thus, while appenLogFile writes to logX.dat, recover will be allowed to read all log files up to and including logX-1.dat but will then have to wait until appendLogRecord starts writing to logX+1.dat.
> All the described changes will only apply when in slave mode

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.