You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Jørgen Løland (JIRA)" <ji...@apache.org> on 2007/11/15 11:40:43 UTC

[jira] Updated: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side

     [ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jørgen Løland updated DERBY-3021:
---------------------------------

    Attachment: derby-3021-2b.stat
                derby-3021-2b.diff

Thanks for reviewing the patch, Øystein. I uploaded a new patch,
v2b, which is modified as follows:

Fixed:

1a,1b,1f,1g,2c: I agree. Fixed.

1c: startSlave, where these property values are used, will be
called immediately after booting the module. The properties
belong to a specific connection, i.e., they have been specified
by the caller of the startSlave command and are not shared
between connections.

If two slaves are started with the same slave port, either
specified explicitly or because both use the default port,
startSlave will throw a StandardException with type
REPLICATION_CONNECTION_EXCEPTION, wrapping a
'java.net.BindException: Address already in use' to the client
calling startSlave last.

1d: ok

1e: inReplicationSlaveMode is volatile already. Does it still
need to be synchronized? The only change that can be made to that
boolean is setting it to false in stopSlave. It is never set to true except
during object creation.

2a: Should have been two sentences. "current log file number. Other
than..." - changed

2b: I thought asserts in sane mode should be used to check that
the method usage was as planned? If another usage of the method
later appeared, the person implementing that usage would be free
to change this method... Not a big deal, though. I made
switchLogFile and appendLogRecord public as suggested.

3: Do you refer to the order of the arguments in
SlaveController#handleLogChunk? If so - fixed.

> Replication: Add a ReplicationSlave controller that will manage replication on the slave side
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3021
>                 URL: https://issues.apache.org/jira/browse/DERBY-3021
>             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: derby-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat, derby-3021-2a.diff, derby-3021-2a.stat, derby-3021-2b.diff, derby-3021-2b.stat
>
>
> The replication slave role includes many tasks:
> * set up a network connection with the master
> * receive chunks of log from the master, and parse these into individual log records
> * append log records to the local log file
> * make sure that the recovery process is not allowed to access the logfile we are currently writing to
> * etc
> This issue is for adding a controller that will start/stop/initiate all services needed for the replication slave role.

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