[
https://issues.apache.org/jira/browse/DERBY-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-3016:
---------------------------------
Attachment: slave_logscan_2.diff
slave_logscan_2.stat
Thanks for reviewing the patch, Dag.
Attaching a new patch, slave_logscan_2, addressing your comments.
I have fixed all your suggestions except the code change in
retrieveLong. I tried to change it, but found the code harder to read
afterwards. Ideally, I would use 0xffL on the first byte as well, but
that one has to be cast.
Since the log format description in ReplicationLogScan was changed to
point to the log buffer package (with a @see tag), I also added a log
format description to the LogBufferElement.java javadoc.
>It provides an abstraction for accessing the incoming log records. The
>'data' and 'optional data' fields are copied once more before they can be
>accessed by the slave redo.
>This seems unncessary since the lifetime of the objects created is
>shorter than the underlying buffer source (logToScan), but may be
>convenient given the usage intended: One needs to get at a byte[]
>array for the data to be present in the shape and form as expected
>for the for the reDo step, perhaps? Guessing..
I was not explicit about this, but you are absolutely right; the data
and optionalData byte[] are needed in their original form. They will
be used as parameters in calls to
org.apache.derby.impl.store.raw.log.LogToFile#appendLogRecord
> Replication: Add code that parses a chunk of log records (byte[]) into
> individual log records
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-3016
> URL: https://issues.apache.org/jira/browse/DERBY-3016
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: slave_logscan_1.diff, slave_logscan_1.stat,
> slave_logscan_2.diff, slave_logscan_2.stat
>
>
> The derby instance that has the slave role for a database 'x' has to redo log
> records sent from the master. These log records are sent in chunks as a
> byte[]. To be useful to the slave, these chunks of log records must be parsed
> into individual log records.
> The actual format of the received log record chunks is defined by the
> replication log buffer (see DERBY-2926).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
