db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2921) Replication: Add a network service that connects the master and slave Derby instances
Date Mon, 10 Sep 2007 12:35:31 GMT

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

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

V.Narayanan (JIRA) wrote:
>> That is certainly OK. I think that by writing tests you get
>> experience in using the interface you have created, and you may
>> realize that parts of interface should be changed. Hence, it is good
>> to write the tests before too much code has been written that rely on
>> the current interface.
> 
> The current code is not used in any part of the codebase for now.
> I find it difficult to factor in tests which would use the code.
> I humbly request that this code be allowed to remain for now and
> promise to write comprehensive tests that shall cover all the
> capabilities of this code once the features that use this code are
> put in.

As I said, it is OK for me to commit this without tests. However, I do
not see that it should be very difficult to write a small test program
that opens a connection and sends a message using you new interfaces.

>> So the slave will not use this code to listen for messages?
> 
> No the communication will only be through the streams obtained from
> the socket after the initial connection has been established.

Either you did not understand my question, or I did not understand
your answer.  I was asking why the class javadoc only talk about
receiving messages from the slave, which you confirmed meant that the
class is only to be used by the master.  So what code will the slave
use to listen for messages?  Will there be another class for that?


>> 1. ReplicationMessageTransmit and ReplicationMessageReceive has much
>>   in common, but the organization of the code differs in several
>>   places. Examples:
>>      - The ...Transmit constructor calls a private function which
>>        does the necessary work while ...Receive has much of the code
>>        in the constructor.
>>      - ...Tramsmit has a separate class for the privileged operation,
>>        ...Receive does not.
>>
>>   I think it would be better if the code was more uniform. Maybe
>>   some of it could even be shared? (E.g., member variables and code
>>   to resolve defaults.)
> 
> I have factored the common attributes and methods into a class
> ClientServerSocketCommon.

Great, I will look at your new patch.

> 
>> 2. Only part of the code in the ReplicationMessage... classes is
>>   particular to replication. For example,
>>   ReplicationMessageTransmit#sendAndReceiveAck is the only method in
>>   that class that has any replication specific code. I think you
>>   should consider to factor out the replication specific code to
>>   separate classes that use your Transmit and Receive classes.
> 
> The transmit class is now broken into 
> 
> ReplicationClientSocketUtil - That contains the Network related methods
> ReplicationMessageTransmit  - That handles the actual transmission of the
>                               messages and the setting up of the connection.
> 
> I could not do the same with ReplicationMessageReceive because the
> receive class actually would be receiving on the client socket and
> then on the Input Stream obtained from this socket. Hence now we
> would have once class that listens on a socket upon receiving a
> message relinquishes control to another which would handle this
> message and again take back control from this class.
> 
> We cannot have multi-threading here because we need the log records
> to be written in the log file in the same order in which they are
> received. If we use threading we would need to schedule these
> threads appropriately which would again become cumbersome.

I did not quite follow this, but note that separate classes does not
necessarily mean separate threads.

> 
>> 3. It is not clear to me what the user contract is for the
>>   ReplicationMessage... classes. I think you need to add Javadoc
>>   that describe how they are supposed to be used, and how they behave
>>   in the normal case (e.g., it needs to be mentioned that
>>   ReplicationMessageReceive#receive does not return until an error
>>   occurs) and in a failure situation (e.g., will they try to
>>   reconnect automatically?). 
> 
> I have added method specifics to the javadocs of all the related
> methods and shall add more information if you think this is not
> sufficient.

Great, I will look at it, and report back.


> Replication: Add a network service that connects the master and slave Derby instances
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-2921
>                 URL: https://issues.apache.org/jira/browse/DERBY-2921
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions: 10.4.0.0
>            Reporter: Jørgen Løland
>            Assignee: V.Narayanan
>         Attachments: Replication_Network_v1.diff, Replication_Network_v1.stat, Replication_Network_v2.diff,
Replication_Network_v2.stat, Replication_Network_v3.diff, Replication_Network_v3.stat, Replication_Network_v4.diff,
Replication_Network_v4.stat, Replication_Network_v5.diff, Replication_Network_v5.stat
>
>
> A network connection is required between the master and slave Derby instances of a replicated
database. The connection will be used to send many kinds of messages, including:
> * log records
> * the database (when replication is started)
> * master -> slave commands (like "stop replication")

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


Mime
View raw message