[ https://issues.apache.org/jira/browse/DERBY-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568907#action_12568907 ]
Øystein Grøvlen commented on DERBY-3382: ---------------------------------------- Comments to the 1a patch: 1. ReplicationMessageReceive#parseAndAckInstant: No need to inform the master in case of an unexpected message sequence? 2. MasterController: If and else parts is identical for both changes. I guess you are supposed to use getHighestShippedInstance() for the if-part. 3. AsynchronousLogShipper: I find the naming of ReplicationLogBuffer#getLastInstant() a bit confusing. I first wondered whether it represented the last instant added to the ReplicationLogBuffer, but I guess it is the last instant of the first chunk of the buffer. 4. LogToFile#getFlushedInstant: Looks very similar to getFirstUnflushedInstant except it returns a long instead of a LogCounter. However, the names seems to indicate that they are different. By the way, the latter is synchronized while the former is not. Is there a justification for that? > Replication: Slave must inform master if DBs are out of sync. > ------------------------------------------------------------- > > Key: DERBY-3382 > URL: https://issues.apache.org/jira/browse/DERBY-3382 > Project: Derby > Issue Type: Bug > Components: Replication > Affects Versions: 10.4.0.0 > Reporter: Øystein Grøvlen > Assignee: Jørgen Løland > Fix For: 10.4.0.0 > > Attachments: derby-3382-1a.diff, derby-3382-1a.stat > > > If I copy the database to the slave before booting the master, slave will be > out of sync with the master since new log records are created during booting. > The slave will then stop replication, but the master will not be notified. > If I then try to stop or failover the master the master will hang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.