db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave
Date Mon, 29 Oct 2007 13:17:51 GMT

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

V.Narayanan updated DERBY-3064:

    Attachment: LogShipperIntegration_v2.stat

Thank you for the comments and reviews Oystein.

>1. AsynchronousLogShipper#shipALogChunk: If resending of
>   failedChunk fails, the current code will set failedChunk to null.
>   Is that intentional?

I guess you are referring to failedChunk being assigned mesg. When
failedChunk transmission fails then mesg would also be null. 

It was my mistake and was not intentional.

I have overcome this by doing

failedChunk = (mesg==null) ? failedChunk : mesg;

mesg is null would imply that a transmission of the failedChunk was being
attempted and failedChunk would not be lost now.

>2. MasterController#setupConnection: Why are IOEXcecptions not
>   reported? Maybe the IOException could contain useful information
>   to figure out a network problem.

I initially thought of reporting IOExceptions here, but IOExceptions
cause setupConnection to return false and a next reconnect is attempted
in half a second. Reporting this failure in log would cause a
IOException to be printed in the log every half a second. Would'nt this
amount to flooding the log? All these IOEXceptions being registered would
contain the same information stating a socket connection exception. So I was
afraid that it would contain the same information being repeated too many times.

>3. MasterController#startMaster:

>   a) Do you depend on the thread to be interrupted before you give up
>      attempting to start replication? (Same issue with
>      handleException)

Yes, the attempt to connect to the slave will persist until it is interrupted.
One thing I can do is to ensure that the attempts are stopped when the user calls
stopreplication. I have attempted to link stopMaster() with this. I did this because
upon retrospection it did not seen right to me that a network connection is attempted 
while the user has called stopreplication.

>   b) InterruptedExceptions are normally trapped since they occur when
>      some code intentionally interrupts the thread.

I was throwing the interrupted exception obtained from Thread.currentThread().sleep(500);.
I have changed it to simply log the exception and throw it no more.

>4. MasterController#stopMaster:

>   a) The setting of the stop state is not synchronized with the log
>      shipper thread. Hence, you have no guarantee for when the log
>      shipper thread will see that the stop field has changed. If you
>      make AsynchronousLogShipper#shipALogChunk volatile, it will be
>      guaranteed that updates to the field are visible to other
>      threads. (An alternative is to make stopLogShipment
>      synchronized, but that is probably more expensive).

>   b) Maybe you should interrupt the log shipper thread to make sure
>      it stops immediately?

I have interrupted the log shipper thread and consequently removed the stopShipping
check from the run() method. I instead have introduced a while(true) loop. I have however
retained the stopShipping check inorder to ensure that a forceFlush call after stopreplication
does not succeed.

>5. Do you plan to internationalize the derby.log messages in a later
>   patch?

Yes, I was hoping that this could be done in a follow up patch if this would be OK
with you.

>6. I suggest you make a method that log the error message, print the
>   stack and stop the master, so you do not have to repeat that many
>   times. 

Introduced printStackAndStopMaster that does the sequence. I thought I could
move the printErrorStack code also in but doing that seemed to clutter a three
step process being modularized. So decided to let it remain this way.

>7. There is an unused import of SanityManager in MasterController.java

I have removed this unused import.

>8. MasterController#startMaster(handleExceptions: Thread.sleep is
>   static, so there is no need to call currentThread().

changed it to Thread.sleep in handleExceptions also.

> Implement the LogShipper that will enable the shipping of Log records from the master
to the slave
> --------------------------------------------------------------------------------------------------
>                 Key: DERBY-3064
>                 URL: https://issues.apache.org/jira/browse/DERBY-3064
>             Project: Derby
>          Issue Type: Sub-task
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>         Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, LogShipperImpl_v2.diff,
LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, LogShipperImpl_v3.stat, LogShipperImpl_v4.diff,
LogShipperImpl_v4.stat, LogShipperImpl_v5.diff, LogShipperImpl_v5.stat, LogShipperIntegration_v1.diff,
LogShipperIntegration_v1.stat, LogShipperIntegration_v2.diff, LogShipperIntegration_v2.stat

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

View raw message