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-3527) The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands
Date Tue, 25 Mar 2008 14:15:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581949#action_12581949
] 

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

Thanks for the patch, Jørgen.  Here are my comments:

1. There seems to be some asymmetry between master and slave with
   respect to what is handled by the controllers and the
   ReplicationMessage classes.  For example, the timeout of the
   new threads are handled by the ReplicationMessageTransmitter on the
   master side, but by the SlaveController on the slave side.  I think
   it would be easier to understand the code if the design was more
   symmetric.

2. ReplicationMessageTransmit:

   a. With this patch there will now be two paths for sending a
      message and waiting for an ack.  I think the class would be less
      complex if the new approach was also used for the initial
      messages. Would this be possible?  I think you also should
      consider whether all verification of acks could be done in a
      single method.

   b. I would be good if you could add some javadoc that gives the
      motivation for a separate thread for receiving messages.

   c. Following the pattern of the other thread names, the database
      name should also be included for derby.master.receiver

3. For the SlaveController/ReplicationMesssageReceive part, it is a
   bit confusing what responsibility lies in what class.  For example,
   both classes has a pingSemaphore for "synchronization of the ping
   thread."  Is that strictly necessary?  It seems to me that more of
   the logic should be moved into ReplicationMesssageReceive.

4. ReplicationMessageReceive#pingMaster: javadoc describes a return
   value, but method is void.




> The slave will not notice that a network cable is unplugged and will therefore reject
failover/stopSlave commands
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3527
>                 URL: https://issues.apache.org/jira/browse/DERBY-3527
>             Project: Derby
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 10.4.0.0, 10.5.0.0
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: derby-3527-1a.diff, derby-3527-1a.stat
>
>
> If a network cable between the master and slave is unplugged (or a switch crashes etc),
ObjectInputStream#readObject will not get an exception. Neither the socket nor the input stream
can be queried for information on whether or not the connection is working. AFAIK, the only
way to find out if the network is down is to send a message.
> The slave commands stopSlave and failover are rejected if the network connection is working.
To be absolutely sure that the connection is working, we need to ping the master when these
commands are requested.

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