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 Tue, 02 Oct 2007 08:04: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: LogShipperImpl_v4.stat
                LogShipperImpl_v4.diff

Thank you for the comments on the patch Oystein. I have addressed all the
issues pointed out. Some explanation for the changes made follows.

> AsynchronousLogShipper, unused import: SQLState

In order to address your comment related to NoSuchElementException I am
throwing a StandardException with SQLState as SQLState.REPLICATION_FATAL_ERROR.
I therefore have retained this import.

>"when the shipper is informed to perform its periodic shipping
>also." I feel this sentence is a bit unclear. What does is mean
>to be "informed to perform its periodic shipping"? 

I meant when a forceFlush wakes up the periodic shipping thread. I have however
rephrased it to say

"  The log shipping happens at the configured shipping intervals unless a
   force flush happens, which triggers periodic shipping also since there
   will still be more log to send after the forceFlush has sent one chunk. "

>AsynchronousLogShipper#shipALogChunk/forceFlush: I am not sure
>that it is a good idea to call handleException when you are not in
>the log shipping thread. In that case, one might as well just let
>the exception go up to the MasterController directly. I would
>also think it is the master controller that should decide whether
>or not to reconnect, not the log shipper on its own. With respect
>to NoSuchElementException, I think you have better knowledge of
>the context in which it is happening here than the
>MasterController will have, and it might be a good idea that the
>log shipper decides how to handle it. Since it will occur if you
>do not get any data even if next() return true, something fatal
>must have happened, and I guess you might as well report back a
>fatal replication error. 

I have changed the shipALogChunk() method to throw its exceptions so that
the run() and the forceFlush() may handle them apropos.

I now catch the NoSuchElementException and wrap it in a StandardException
with a SQLState as SQLState.REPLICATION_FATAL_ERROR.

The IOException caused by a connection failure is also thrown, no reconnect
is attempted.

forceFlush() throws all its exceptions to master controller. I am wrapping the
IOException obtained while calling shipALogChunk in a StandardException since
its signature in LogShipper mandates that a StandardException is what is throw.

run() calls handleExceptions.

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


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