[
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.
